XMPP is a family of protocols for exchanging XML streams, messages, and presence information. Understand it by following a small exchange: a client connects to its server, establishes its identity, and sends a stanza that the server routes to a recipient.
Follow the addressing path
A Jabber ID, or JID, can have the form user@domain/resource. The domain identifies the service; a resource can identify a particular connected endpoint. A bare JID omits the resource. Routing to a bare address and routing to a specific resource have different consequences when an account has several devices.
In a fictional exchange, ada@example.org/laptop sends a message to ben@example.net. Ada's client uses its own server; that server can communicate with Ben's domain through server-to-server federation. Each deployment controls whether federation is permitted. The XMPP Core specification, RFC 6120, defines streams, negotiation, addressing, and stanza handling.
Recognize the three basic stanza families
| Stanza | Purpose | Interpretation |
|---|---|---|
| message | Deliver content such as a chat message | A body carries text; extensions can add other features. |
| presence | Share availability and manage subscriptions | Availability applies within the relevant presence and subscription rules. |
| iq | Request structured information or a change | A get or set request receives a result or error with a matching ID. |
Presence can indicate that an endpoint is available. A read indication requires a separate supported mechanism. The instant messaging and presence specification, RFC 6121, supplies the detailed behavior for rosters, subscriptions, and chat routing.
Read a small message trace
This fictional server-routed stanza uses reserved example domains. It is an illustrative fragment, not a full connection transcript:
<message xmlns="jabber:client"
from="ada@example.org/laptop" to="ben@example.net"
type="chat" id="m-17">
<body>The reading list is ready.</body>
</message>jabber:client identifies the client stanza vocabulary. The server verifies or supplies the sender identity according to the authenticated session. The body is plain text in this example. A server-to-server stream uses its own stanza namespace, so copying this fragment into a different stream context requires understanding that context.
For an IQ request, record the request's id, intended recipient, and expected payload namespace. Match a response by ID and verify its result or error type. A timeout means the request did not complete within your chosen deadline; diagnose the stream, routing, and recipient before retrying a state-changing operation.
Choose features and verify what happened
Core XMPP supplies the foundations. Additional capabilities are described in XMPP Extension Protocols, whose maturity and implementation support vary. Before choosing clients and servers, list required features such as group chat, history synchronization, delivery receipts, and encryption, then test the exact combination.
TLS protects a connection between endpoints of that connection. End-to-end message encryption has separate client, key, and extension requirements. Document which parties can see content and metadata in the chosen configuration. A successful connection alone is insufficient evidence for the entire privacy requirement.
Use two controlled accounts to test same-domain and permitted cross-domain delivery, disconnect/reconnect behavior, multiple resources, and visible failures. Separate server acceptance, recipient delivery, and a user read indication in logs and UI. Repeating a test after upgrades helps detect changed extension support or routing behavior. The XMPP Standards Foundation overview connects the core protocols with the wider ecosystem.