XMPP

The eXtensible Messaging and Presence Protocol

Ralph Meijer

Overview

Started in 1998 as Jabber
Routing platform for structured data
Real-time
Most well-known use case: instant messaging

Advantages

Open
Standard
Proven
Decentralized
Secure
Extensible
Flexible
Diverse

Open

Free, open, public, and easily understandable
Multiple implementations in:
- clients
- servers
- server-side components
- libraries

Standard

IETF approved instant messaging and presence protocol
Published as RFC 3920 and RFC 3921 in 2004
Revised RFC 6120, RFC 6121 (2011), and RFC 7622 (2015)
WebSocket binding as RFC 7395 (2014)

Proven

Development started in 1998 by Jeremie Miller
Hundreds of developers
Tens of thousands of XMPP servers
Millions of people
Starting point for a number of large IM services

Decentralized

Architecture similar to e-mail
Addressable end-points

Secure

Transport Layer Security (TLS) for channel encryption
SASL for authentication:
- Flexible authentication mechanisms
- Discovery
- Reuse of standard mechanisms
- Allows custom mechanism
- Future-proof

Extensible

Builds on XML
XML Namespaces for distributed extensibility
Common extensions as XEP series
Anyone can do private extensions

Flexible

Beyond Instant Messaging:

Network management
Collaboration tools
Multimedia signalling
Internet of Things (IoT)
…

Diverse

Wide range of companies
Open source projects
No vendor lock-in

Core

Default binding: XML Streaming over TCP
TLS for channel encryption
SASL for strong authentication
Full Unicode (includes addressing, emoji 😃)
Built-in information about network availability (presence)
Presence subscriptions for two-way authorization
Presence-enabled contact lists (rosters)

Addressing

A Jabber Identifier (JID) has one of three forms:

`example.org`	server
`localpart@example.org`	user, room, device, etc.
`localpart@example.org/tablet`	specific instance

Addressing features

Every entity (client instance, server, device, chat room) is addressable using a JID
Servers interconnect based on the domain part of the JID
Servers check sender addresses, no relaying

Stanzas

`presence`	Publish-subscribe for entity availability
`message`	One-off messages
`iq`	Request-response semantics

For each there are stanza-level (extensible) errors

Presence

Client sends presence to its server:


<presence>
  <show>away</show>
  <status>Away from keyboard</status>
</presence>

Server broadcasts presence:


<presence from="user@example.org/Tablet"
          to="other@example.com/mobile">
  <show>away</show>
  <status>Away from keyboard</status>
</presence>

Message


<message from="user@example.org/Tablet"
         to="other@example.com"
         type="chat">
  <body>Hello, world!</body>
</message>

Message

lightweight markup


<message>
  <body>Wow, I'm green with envy!</body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p style='font-size:large'>
        <em>Wow</em>, I'm <span style='color:green'>green</span>
        with <strong>envy</strong>!
      </p>
    </body>
  </html>
</message>

Wow, I'm green with envy!

Message

publish-subscribe notification


<message from='portia@merchantofvenice.lit' 
         to='bassanio@merchantofvenice.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='http://jabber.org/protocol/geoloc'>
      <item id='d81a52b8-0f9c-11dc-9bc8-001143d5d5db'>
        <geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
          <lat>45.44</lat>
          <lon>12.33</lon>
          <accuracy>20</accuracy>
          <locality>Venice</locality>
          <country>Italy</country>
        </geoloc>
      </item>
    </items>
  </event>
</message>

IQ


<iq type='get' id='info4'
    from='juliet@capulet.com/balcony'
    to='romeo@montague.net/orchard'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>


<iq type='result' id='info4'
    from='romeo@montague.net/orchard'
    to='juliet@capulet.com/balcony'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='client' type='pc' name='Gabber'/>
    <feature var='jabber:iq:time'/>
    <feature var='jabber:iq:version'/>
  </query>
</iq>

Service Discovery

Discovering information about other entities
List entities
Supported protocols, features
Configuration and meta-data
Entity Cabilities ⏷

Entity Capabilities

Optimization to prevent disco floods
Caching
Quickly determine supported features of contacts' clients:
- Rich text
- File transfer
- Audio/video for Jingle conferencing
Also used for filtering notifications in Publish-Subscribe

Publish-subscribe

Framework for subscription based push messages
Server-mediated
Topic or content-based subscriptions
Personal Eventing

Jingle

Set up, manage, and tear down multimedia sessions
Voice, video, file transfer, gaming, etc.
Signaling over XMPP
Media transport usually peer-to-peer or via relay
Semantically consistent with SIP: enables gateways
Very suitable for use with WebRTC

XMPP in Mobile

Bandwidth: compression, caching, resumption
Power consumption: postpone / bundle traffic (e.g. presence)
Unstable connections: keepalives, stream resumption
Push notifications (wake offline client through APNS, GCM, etc)

Multi-user Chat

Multi-party information exchange in rooms
Presence, private messages, invites
Not only plain-text: meta-data, games, etc.
Room control: moderation, restricted access
Multi-party multimedia conferencing
Future development as MIX ⏷

Mediated Information eXchange (MIX)

Based on Publish-Subscribe
Offline participation
Presence exchange is optional
More robust message archiving
Better support for other data formats (files, structured data, multimedia conferences)
Flexibility about which data formats to receive

Data Forms

Light-weight forms processing
E.g. service configuration, data description, reporting
Common data types (boolean, list, text)
Extensible

Modern IM

Message synchronisation between devices
Message archiving
Embedded pictures, audio/video, locations
Markup for mentions, rooms/channels
Integrations / bots