9  XMPP Presence and Federation

XMPP Core, JIDs, Service Discovery, PubSub, IoT Extensions, and Selection Evidence

protocols
application-protocols
xmpp
messaging
technology-selection
Keywords

XMPP IoT, XMPP protocol, XMPP stanzas, JID, XMPP PubSub, XMPP service discovery

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.

In 60 Seconds

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.

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

9.2 Reference Anchors

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

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.

9.3 XMPP Review Route

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

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

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

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.

9.4 Architecture Roles

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.

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.

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.

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.

9.5 Stanza Roles

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

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

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

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.

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

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

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.

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

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

XMPP presence and PubSub flow

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.

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

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

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

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.

9.9 Protocol Fit

XMPP is one candidate in a protocol portfolio. Compare it by evidence, not by slogans about XML or decentralization.

XMPP protocol fit record comparing semantics, identity, discovery, transport, security, operations, field validation, and alternatives.

XMPP protocol fit record comparing semantics, identity, discovery, transport, security, operations, field validation, and alternatives.

Use XMPP when several of these fit signals are true:

  • The application needs first-class presence or availability state.
  • JID-based identity and directed messaging are useful.
  • Service discovery or feature advertisement matters.
  • PubSub nodes, access models, or stored items are needed.
  • Federation across administrative domains is a real requirement.
  • Human-device interaction, chat-like control, or collaboration is part of the product.
  • The team can operate XMPP servers, certificates, logs, abuse controls, and extension compatibility.

Use a simpler path when the workload is mostly constrained telemetry, fixed-topic publish/subscribe, RESTful device access, brokered enterprise messaging, or raw realtime browser communication without XMPP semantics.

9.10 Core Technologies, Limits, and Uses

XMPP is a family of XML-stream technologies, not a single “chat” feature. Core XMPP provides the stream, stanza, addressing, authentication, and routing base. Jingle adds session negotiation for voice, video, and file-transfer style media workflows. Multi-user chat supports group conversation rooms. PubSub provides nodes, subscriptions, publications, and notifications. BOSH carries XMPP over HTTP request pairs when a WebSocket or native TCP stream is not available.

Those capabilities have costs that matter in IoT reviews. XMPP has no native MQTT-style QoS 0/1/2 delivery contract, so reliability evidence must come from stanza acknowledgments, stream management, application state, or the chosen extension. Text XML increases network overhead, and binary data normally has to be encoded, such as with base64, before it can travel inside XML. That makes XMPP a poor fit for high-rate binary telemetry from constrained devices unless the gateway or server layer is doing the XMPP work.

Good XMPP candidates include publish-subscribe systems where PubSub policy matters, VoIP or media signaling through Jingle, file transfer coordination, social or collaborative services, gaming presence, smart-grid coordination, and cross-domain IoT workflows where identity, discovery, or presence is a product requirement. If the application only needs simple telemetry fan-out, MQTT or AMQP is usually easier to prove.

9.11 Worked Example: Facility Operations Presence

Scenario

A facility operations team wants maintenance tablets, room controllers, alarm panels, and supervisory dashboards to show each other’s availability and exchange low-volume directed messages. The system also needs a controlled way to discover device capabilities after maintenance replacement.

Why XMPP remains in scope

  • Presence is part of the user workflow.
  • Directed messages and identity matter.
  • Service discovery can expose capabilities without a separate registry.
  • WebSocket transport may help browser-based operator tools.

Evidence needed

  • Server support for client streams, resource binding, TLS, SASL, roster or presence policy, and selected extensions.
  • JID naming and deprovisioning policy for people, devices, rooms, and applications.
  • Access-control rules for presence subscriptions, discovery, PubSub nodes, and control commands.
  • Failure tests for offline devices, duplicate resources, stale presence, rejected IQ requests, and federation failures.
  • Alternative comparison against MQTT, AMQP, HTTP/WebSocket, or CoAP for non-presence telemetry flows.

Decision

XMPP is a reasonable shortlist candidate for the interactive, presence-aware layer. It should not automatically carry high-volume telemetry unless field evidence shows the selected stack and operations team can support that path.

9.12 Common Pitfalls

Avoid These XMPP Review Mistakes
  • Treating XMPP as a universal IoT replacement for MQTT, AMQP, CoAP, HTTP, or WebSocket.
  • Claiming XML overhead is always decisive without checking absolute workload, transport, power, and feature needs.
  • Assuming federation is required when all devices live under one administrative domain.
  • Exposing service discovery or presence broadly without privacy and authorization review.
  • Citing XEP support without proving the selected server and client libraries implement the exact extension behavior.
  • Using presence as a substitute for health monitoring, audit logs, retry policy, or device lifecycle management.
  • Ignoring certificate, DNS, trust, abuse, logging, and monitoring work for server-to-server federation.

9.13 Knowledge Check

Check: Stanza Choice
Check: Match the Role

Check: Order the Review

9.14 Concept Relationships

JID plus stanza defines the route. The JID identifies the entity and resource; the stanza family defines the type of interaction.

Presence is semantics, not telemetry. Presence can show availability and status transitions, but health monitoring still needs logs, alerts, retries, and lifecycle records.

Discovery needs authorization. Service discovery is useful for capability review, but exposing entity identities and features can create privacy and security risk.

PubSub is not just MQTT with XML. XMPP PubSub has nodes, subscriptions, access policy, notifications, and optional stored items. It should be chosen only when those semantics matter.

Federation is an operations commitment. Cross-domain messaging adds DNS, certificates, trust, policy, abuse controls, and monitoring work.

9.15 Deep Dive: How XMPP Moves, and Why It Is Heavy

The sections above cover XMPP’s roles and evidence. This layered walkthrough shows the mechanism underneath: XMPP is a long-lived XML stream rather than request/response, it carries everything as one of three stanzas, and its XML verbosity is exactly why it sits at gateways and servers while MQTT and CoAP sit on the constrained edge.

HTTP is stateless: a client asks, the server answers, and the exchange ends. XMPP is the opposite. A client opens one persistent TCP connection to its server, normally on client-to-server port 5222, secures it with TLS, authenticates with SASL, binds a resource, and then exchanges XML stanzas over that open stream until it closes. That always-open stream is what makes presence and pushed messages natural, and also what makes XMPP expensive for a tiny sleeping device.

Use XMPP when the stream semantics are part of the requirement: presence, routed messages, discovery, human-device interaction, or federation. A sleeping sensor that reports every hour usually wants a cheaper store-and-forward protocol. If XMPP is justified, document reconnect behavior, keepalive interval, TLS certificate policy, offline queue limits, and who may subscribe to presence.

Everything XMPP does is carried by one of three stanza types, each addressed with a JID of the form localpart@domain/resource. A presence stanza announcing that a field sensor is online and available looks like this:

<presence from='sensor7@gw.example/field'
          to='ops@gw.example'>
  <show>chat</show>
  <status>online</status>
</presence>

The from JID names both the account, sensor7@gw.example, and the specific connected resource, /field. <show> gives availability and <status> carries free text. Keep the stanza roles separate so retry, timeout, and audit behavior stay clear.

Stanza Pattern IoT use
<message> Fire-and-forget delivery; no reply expected Push an alert, notification, or PubSub event
<presence> Publish and subscribe to availability Know whether a device, gateway, or operator is online now
<iq> Request/response with get, set, result, or error Service discovery, configuration, PubSub management, and bounded control queries

The request/response nature of <iq> is especially important for configuration and discovery. A controller can correlate the returned result or error with the original request, apply a timeout, and decide whether to retry or surface a failed capability check. A pushed <message> may be useful, but it does not prove that a queried field exists. Log the stanza id with each result so support can trace failed queries through retries.

XMPP’s native transport is the long-lived RFC 6120 TCP stream secured with TLS. Two web bindings let the same XML stream traverse HTTP-only infrastructure: XMPP over WebSocket, defined by RFC 7395, carries the stream inside one WebSocket connection, while BOSH, XEP-0124, emulates the stream over HTTP long-polling for environments that permit nothing but HTTP.

sequenceDiagram
  participant C as Client (sensor7)
  participant S as XMPP server
  participant O as Subscriber (ops)
  C->>S: TCP connect, then STARTTLS
  C->>S: SASL auth and bind resource
  Note over C,S: One long-lived XML stream stays open
  C->>S: presence stanza (online)
  S->>O: server routes the stanza
  O->>S: iq get (query features)
  S-->>O: iq result over the open stream

The cost is verbosity. Every stanza is XML: element tags, namespaces, and full JIDs. That is bulky next to MQTT’s small fixed header or CoAP’s compact UDP framing. For a coin-cell sensor, both the framing overhead and the always-open TCP stream are expensive, so XMPP usually belongs at gateways, servers, and dashboards where presence and federation earn their cost. MQTT-SN or CoAP typically fit the constrained edge better. Where XML is mandated, EXI (Efficient XML Interchange) can compress it.

Protocol Model and framing Fit
XMPP XML stanzas over a long-lived TCP stream, WebSocket, or BOSH Presence-rich messaging, discovery, and federation at gateways and servers
MQTT Publish/subscribe over a long-lived TCP connection with compact MQTT framing Brokered telemetry and event fan-out from capable devices and gateways
CoAP REST-style UDP/DTLS protocol with compact messages and Observe for push Constrained edge devices needing request/response plus lightweight observation

Federation is a separate operations commitment. Server-to-server links, commonly on port 5269, let one domain’s entities message another domain’s entities, but each link adds DNS, certificate, trust, policy, monitoring, and abuse-control obligations.

Before choosing XMPP for IoT, write the evidence record in three lines: the XMPP semantic you need, the exact server/client/XEP support you verified, and the simpler protocol you rejected with a concrete reason.

9.16 See Also

Standards and XMPP detail

Course context

9.17 Summary

XMPP brings standards-based addressing, presence, federation, PubSub, and XML stanza semantics into IoT architecture reviews. It fits when identity, discovery, human-device workflows, or cross-domain messaging matter enough to justify server, extension, security, and operational complexity.

9.18 Key Takeaway

Use XMPP for IoT only when presence, discovery, addressing, or federation semantics justify the extra XML, server, extension, and operations complexity.

9.19 What’s Next

Choose the next chapter by the decision still open: