Jabber and XMPP: sessions, stanzas, standards
How an XMPP session opens, what the three stanzas message, presence and IQ carry, how the protocol reached the RFCs, and what a client or a federated server
A Jabber, now XMPP, session opens when a client sends an XML stream header to a server, negotiates TLS, authenticates, then binds a resource to its JID. Once the stream is live, the client and server exchange three stanza kinds: message for content, presence for availability, and IQ for request and response pairs. Everything else in the protocol, from contact lists to multi user chat, is built on those three elements.
What happens when a session opens
The opening sequence is a stream negotiation, not a single login call. The client connects to the server named in its JID, sends an opening stream tag, and waits for the server's own opening tag. The server then advertises features, and the two sides upgrade the connection to TLS before any credential crosses the wire. Authentication follows, historically with SASL mechanisms such as PLAIN over the encrypted channel, and the server confirms success. The client then binds a resource, which is the arbitrary label that distinguishes one connected device from another under the same bare JID, and the server assigns or accepts a full JID of the form localpart@domain/resource. Finally the client requests its roster, the stored contact list, and receives it as a series of roster pushes. Only after that does the session count as usable.
A reader who wants the exact element order, the namespace declarations, and the point at which each feature is advertised can follow the sequence in the XMPP session and stanza reference, which documents the stream negotiation step by step alongside the RFC text. The practical consequence is that a client which appears to hang on connect is usually waiting on one of these steps rather than failing outright, and server logs show which tag was last exchanged.
What do the three stanzas carry?
Message, presence, and IQ are the only top level stanza types in XMPP, and each has a distinct job.
- Message carries content addressed to a JID. It has a type attribute, commonly chat, groupchat, headline, or error, and a body element holding the text. It is fire and forget: the protocol does not guarantee delivery or ordering, and extensions such as message delivery receipts or carbons exist precisely because the base stanza does not report what happened.
- Presence carries availability. A presence stanza with no type means available, while type values such as unavailable, subscribe, subscribed, unsubscribe, and unsubscribed drive the subscription handshake that populates a roster. Presence is broadcast to contacts who have subscribed to it, which is why a status change is visible to a list rather than to one recipient.
- IQ, short for info query, carries request and response pairs. It has a type of get, set, result, or error, an id that pairs a response with its request, and a payload in a separate namespace. Roster retrieval, version queries, disco requests, and most configuration changes travel as IQ. A server or client must answer every IQ of type get or set, even if only to return an error.
Because the payload namespaces do the real work, the three stanzas stay stable while features accumulate around them. That separation is the reason a client can implement a new extension without changing its core parser.
How did the protocol reach the RFC standards?
Jabber began as a server project in 1998 and 1999, with the name referring to both the software and the network. The protocol was submitted to the IETF, and the core specifications were published as RFC 3920 for the core protocol and RFC 3921 for instant messaging and presence in October 2004. Those two documents defined streams, TLS and SASL negotiation, stanza semantics, and the roster. They were later revised and split: RFC 6120 covers the core, RFC 6121 covers instant messaging and presence, and RFC 7622 covers address format, all published in March 2011.
The name Jabber remained with the original company, while the protocol itself was renamed XMPP, for Extensible Messaging and Presence Protocol, so that the standard carried a neutral label. Extensions live in a separate track: the XSF publishes XEPs, and a XEP moves through Experimental, Draft, and Final states, with some becoming RFCs later. End to end encryption followed the same path, from OpenPGP and OTR era approaches to OMEMO, which applies the double ratchet to XMPP and is specified as a XEP rather than an RFC. Group chat is defined in the multi user chat XEP, and the newer MIX work addresses some of MUC's architectural limits.
What does running a client or a federated server take?
On the client side, the constraints are mostly about the platform. Mobile clients must survive background suspension, so they rely on push notifications or on a server side archive to catch up on messages missed while the app was not running. Desktop clients have more freedom but still differ in which extensions they implement, so a feature that works in one client may be absent in another. Choosing a client is therefore a matter of matching supported XEPs to the features actually needed, not of picking a single best option.
On the server side, three implementations cover most deployments: ejabberd, Prosody, and Openfire. Each handles accounts, roster storage, offline messages, and federation with other domains. Federation is the part that requires the most care, because it depends on DNS. A domain that hosts XMPP publishes SRV records pointing to the service, and the certificate presented during TLS must match the XMPP domain rather than only the host name. A misconfigured SRV record or a certificate for the wrong name will break federation silently from the user's point of view: local accounts work, remote contacts never appear online.
What is the JabberPowered directory?
JabberPowered is a badge and directory programme that dates to 2003, when site operators could display a badge linking their XMPP address or service. The badge is governed by a licence and terms of use rather than being freely redistributable, and the directory lists participating addresses and servers. It belongs to the earlier, more decentralised period of the network, before the protocol's standardisation under the IETF and the XSF, and it survives as a record of how addresses were published when there was no central account system.
Why does the distinction between Jabber and XMPP matter?
It matters for reading documentation. Older texts use Jabber for both the protocol and the network, and newer texts use XMPP for the protocol while Jabber persists in client names, server names, and community usage. When a specification says XMPP, it means the IETF standard and its RFCs. When a directory or a badge says Jabber, it usually refers to the network and its historical identity. A reader who keeps that split in mind can move between a 2003 directory entry and a 2011 RFC without assuming they describe different systems.
The same split explains why the three stanzas have outlasted every change around them. Streams gained TLS and SASL, addresses gained a formal grammar, encryption gained a ratchet, and group chat gained new designs, but message, presence, and IQ still carry the traffic. For anyone installing a client or standing up a federated server, that is the stable part: get the stream open, get the roster loaded, and the rest is a matter of which extensions the deployment chooses to support.
A folio is edited before it is drawn: images are ordered, captioned and checked at file level, and the same discipline applies to any single piece shown on its own. A drawing that carries a caption, a stated size and a clean export survives being looked at closely, which is the only test that matters once the work leaves its author. The ordering rules, caption conventions and technical checks a portfolio has to pass are set out on the portfolio page of this reference, and they apply equally to one image or forty.
Illustration work stays at the application layer, but the hardware underneath it follows its own rules, and a reader who wants to know how a drawing tablet or a capture card actually reaches the CPU can follow that thread in the same reference. The note on PCIe lanes and link training explains how lanes are counted and made up, what happens during LTSSM link training, and where the PIPE interface sits between controller and PHY. It is a hardware note, not an art one, and it is written for readers who want the transport layer spelled out.