Protocol
XMPP uses a stream of XML as the basis for transmitting data. Three main elements are defined by the standard (as well as a few extra ones used primarily for stream negotiation at login): message, presence, and iq (info-query), which all have slightly different delivery semantics. Each of these elements has to and from attributes, indicating sender and recipient.
Unlike SMTP, it’s very difficult to forge the "from" address. If I’m david@example.com, and I send a message to editor@informit.com, the first step is for me to send the message to the server on example.com, which checks the "from" address (or just replaces it). So it’s not really worth bothering to add a "from" address for outgoing stanzas, since it will just be removed. The server on example.com will then connect to the server on informit.com. The receiving server performs a domain name lookup on example.com, to see whether it maps to the IP address from which the connection originates. If not, the connection is refused. The receiving server verifies that my server is who it says it is, and my server vouches for me.
A message stanza is for simple one-to-one communication. If you’re using an XMPP-enabled IM client, this kind of stanza makes up most of your communications. Messages can be very simple, containing just a plain-text body; or more complex, containing XHTML markup, delay timestamps, and a host of other metadata. Since it’s XML, any other (properly namespaced) XML format can be embedded, such as SVG. Clients that don’t understand it have an easy way of ignoring it.
The other common stanza type is presence. The biggest mistake with XMPP 1.0 was making presence a specific type, rather than providing a generic multicast format. When you send a presence stanza, everyone who has you in their contact list ("roster") receives a copy of it if they’re online. If they’re offline, they receive a copy of the last one you sent, when they log back on. This coordination is achieved by a backward-link in your roster; it stores a list of people who have subscribed to your presence information, as well as people to whose presence information you have subscribed.
The problem with the presence mechanism is that the protocol designers didn’t foresee how useful multicast would be. A simple presence stanza updates the online state and optionally a status message. It’s also common now to include some or all of the following information:
- Hash of the user’s avatar
- User’s preferred nickname
- Summary of the client capabilities
- Information about vcard updates
Since users who log on receive only a copy of the last presence sent; changing any of these in the client requires the entire stanza to be re-sent. On a network connection with a decent speed, this isn’t a huge problem, but when connecting via GPRS, it can be surprisingly slow—and expensive, although still much cheaper than SMS.
The final kind of stanza is the info-query node, which follows a strict request-response semantic. When receiving the request component, the receiver should always reply with either a success or error message. These IQ stanzas don’t map directly to IM functions, but are used heavily in some of the more advanced parts of the protocol. A common example is roster manipulation. Retrieving and modifying your contact list is done by sending IQ stanzas to the server.