Purpose
Isode plans to add an XMPP Server to its product set, in order to provide
presence and real time messaging services. XMPP is the Internet Standard
eXtensible Messaging and Presence Protocol, sometimes referred to as
Jabber. This paper sets out:
- Why Presence and Real Time Messaging are important to Isode's customers
and markets.
- Why XMPP, and not another technology.
- Why Isode is building a product, rather than integrating with available
XMPP servers.
- An outline of what Isode will be providing.
Feedback on this strategy and input on product requirements are welcome.
How does XMPP Work?

XMPP defines protocols for communicating between a client and a server,
and between two servers, as illustrated above. An XMPP Client will talk
to the server with which it is registered.
XMPP Clients are named in the same way as email addresses (e.g., Juliet@capulet.com)
and XMPP Servers are named as domains (e.g., capulet.com is juliet@capulet.com's
XMPP server).
XMPP Messages are extensible, and can be used to carry messages of
different types. For example, an XMPP Message can carry Instant Messaging
(IM) type traffic. To send a message, an XMPP Client will simply send
it to its local server. If the recipient XMPP client uses the same XMPP
server, the XMPP server will send it directly to the recipient. If the
recipient uses a different XMPP server, the XMPP server will send the
message to the recipient's XMPP server. There are some key differences
between this scenario and traditional store and forward messaging (email):
- XMPP messages have a single recipient only.
- Messages delivery is optimized for clients that are online (i.e.,
to clients that are connected to their XMPP server).
- Messages do not have to be stored reliably (e.g., on a disk), so
may be dropped if the XMPP server fails.
- XMPP servers are generally optimized for short messages (1 kbyte
or less).
This scenario is familiar to many IM users, although many of the well
known IM services are single server and do not communicate with other
servers in the way that XMPP does. Although IM is an important and well
known use of the messaging part of XMPP, it is important to understand
that the messaging part of XMPP can be used to carry data other than
IM.
XMPP Clients can be interactive GUIs or applications. The basic messaging
part of XMPP can be used as a building block for more complex applications,
and in particular to transfer XML data defined in support of other applications.
Chat rooms are an extension to the core XMPP service, providing a mechanism
for multiple users to exchange and share information.
In order for this messaging to work usefully, a mechanism is needed
to determine if and where a client is online. This is handled by the
Presence part of XMPP. When an XMPP Client connects to its server, its
basic presence is registered, which can be qualified by additional information
provided by the XMPP user, such as "in a meeting" . Thus the
XMPP server has presence information for all local clients. Each XMPP
Client maintains on the XMPP server a list of users, called a Roster
(described as Buddy List and other informal terms in many clients).
The XMPP server determines presence status for each member of the roster,
and keeps this information up to date. This requires XMPP servers to
share presence status of their clients, to enable information on each
client's roster to be kept up to date. The functionality to manage presence
in a distributed environment is the hard part of XMPP.

XMPP provides a mechanism for XMPP clients to exchange messages through
the XMPP servers. This message exchange can be used "as is",
for example to support IM traffic. This message exchange can also be
used to enable two applications using XMPP clients to establish a direct
connection. A good example of this is the JINGLE mechanism based on
XMPP that enables a direct connection to be established for voice traffic
(which has too high a data volume to be sent indirectly through the
XMPP servers). The presence part of XMPP is critical, as in general
the clients would not have a fixed location. XMPP can play a key role
in establishing advanced communication directly between two clients.
XMPP has been widely adopted, including by Google as part of Google
Talk, and there are many XMPP clients and servers available. Technical
information on XMPP can be found on the XMPP
Standards Foundation (XSF) Web site.
Why Real Time Messaging?
IM, based on real time messaging, has become mainstream. Users increasingly
expect to have IM provided alongside email (store and forward messaging).
Real time messaging is an important building block for distributed systems
that can be used in conjunction with store and forward messaging.
Why Presence?
Presence is not such an obvious service to the end user, but it is
critical both to enable services such as IM and to enable direct client
to client communication. It is a key building block for advanced communication
applications.
Why XMPP?
Isode believes that XMPP will become the single standard for Real Time
Messaging and Presence services, and will be providing an XMPP server
and XMPP capabilities in other products.
Presence and IM are on their way to becoming universal services. In
support of this, users will want to have a single IM/Presence address
that can be used with everyone. For many users, it would be convenient
to have this address the same as the user's email address. XMPP enables
this.
Today, many users advertise multiple IM addresses associated with different
centralized IM service providers such AIM, MSN and Yahoo!. This is reminiscent
of messaging in the 1980s, when users would list a set of email providers,
such as AOL and CompuServe. Isode believes that convergence will happen
for IM, in an analogous way to the way that email convergence happened.
Convergence requires an open standard supported by a recognized standards
body, that defines both client/server and server/server operation. Instant
Message and Presence Service (IMPS) from the Open Mobile Alliance meets
two of these criteria, but does not define a server to server protocol,
which is key for an integrated global service.
SIMPLE (Session Initiation Protocol for Instant Messaging and Presence
Leveraging Extensions) is an Internet Standard, and the only serious
alternative to XMPP. Isode believes that XMPP has already won out over
SIMPLE for a number of reasons:
- XMPP has a much larger deployed base, and is actively deployed in
a distributed manner using server/server communication.
- The core SIMPLE specification is significantly more complex than
XMPP.
- Scaling analysis shows that XMPP scales to large deployments in
a much better manner than SIMPLE.
- There are many more XMPP client and server products.
- XMPP has a very active community centred on the XMPP Standards
Foundation that is working on a wide family of standards based around
XMPP.
In summary, we believe that XMPP is the only credible open standards
choice.
Why an Isode XMPP Product?
There are many XMPP servers available, both commercial and Open Source.
This section explains why we are choosing to build a new server:
- Those looking for messaging solutions will increasingly expect to
get both real time and store and forward messaging as part of a single
solution. Integrated management and provisioning is important.
- We expect to be able to offer better performance and scaling than
competing products.
- We expect to offer security features that are not widely available,
in particular strong authentication
- XMPP has a relationship to other products and capabilities, and
achieving close integration with a third party XMPP server did not
appear practical. The integration with and relationship to other Isode
products is examined more closely in the rest of this paper.
XMPP and Directory
Directory and XMPP presence deal with complementary information on
a user:
- Directory holds static information, such as email address and telephone
number.
- An XMPP server holds information that may not always be available
and may change rapidly, such as location and activity.
There is immediate benefit in providing integration of this information
in both directions:
- The directory can be used to hold static information for the XMPP
server, including user information, and rosters. This approach is
consistent with Isode's general approach of using directory to hold
configuration information for Isode applications.
- Presence information stored in the XMPP server can be made available
to directory clients, so that when information is looked up, this
information is available to the directory use along with other information.
For a white pages application, this would enable presence information
such as “User in meeting until 11:30” to be displayed
along with email address and other directory information. It would
also enable an application making information delivery decisions to
make use of presence information in the calculation.
XMPP and Store & Forward Messaging
Isode's store and forward messaging solutions are designed for high
reliability environment. A key goal of many such environments is timely
delivery, and an XMPP service can help here.
Isode provides monitoring capabilities, so that an operator can determine
when messages have not been read by the intended recipient. (see here
for more details). An XMPP service will help the operator in this situation,
by providing information on availability of the intended recipient,
and a mechanism to communicate with the intended recipient using IM
to determine if the message can be handled soon. In the event that the
operator determines that the message needs to be sent on to an alternate
recipient, the XMPP capabilities can be used to help select an alternate
recipient who is ready to handle the message immediately.
It can also make sense to automate the previous operator assisted scenario.
Where a message may be processed by one of several recipients, presence
information can be used by the store and forward messaging system to
help automatically determine the best place to deliver the message.
XMPP and Events
Isode has a model of events and faults described in the Isode white
paper Operational Monitoring and
Control of Systems using Isode Servers. When an event or fault occurs
that (may) require operator attention, it is important to provide a
flexible approach to get this information to an operator. Isode will
extend its event system to provide XMPP alerting of events, either to
an individual user or to a chat room.
This approach can be particularly helpful where the number of operator
events is very low, and operators are handling many non-operational
tasks. Use of a chat room can also be helpful where a number of people
are providing cover. That chat room can then also be used to work out
who is dealing with a specific event, and avoid duplication of effort.
XMPP Security & Strong Authentication
Isode sells to customers who have high security and reliability requirements.
Isode’s XMPP server will pay close attention to features in this
area, such as audit capabilities and access controls. Authentication
is of particular importance.
XMPP uses SASL (Simple Authentication and Security Layer) for authentication,
and this will be shared with other servers using Isode's SASL
support. This integrated authentication approach is important, as
it enables common authentication and shared passwords between XMPP and
other applications.
Strong Authentication
based on X.509 PKI is planned for XMPP, as a part of Isode's general
approach to broadly support strong authentication. This will be client/server
and server/server. XMPP support strong authentication based on the underlying
authentication provided by TLS (Transport Layer Security) and integrated
with the SASL EXTERNAL mechanism. This approach to strong authentication
is a part of the XMPP specification, but is not widely implemented.
Isode’s strong authentication will be closely integrated with
directory.
XMPP Server and User Configuration
 |
Click image for more detail |
Isode provides Web based configuration of its Internet messaging servers
using Internet Messaging Administrator (IMA). This will be extended
to support XMPP.
When a user is added, XMPP support will be selectable as an option,
leading to integrated support with email address and XMPP address being
the same. This integrated provisioning is provided using a directory
back end, and so can be easily be integrated with a third party provisioning
system to give the same result.
Configuration of the XMPP server itself will also be done using directory
and with GUI configuration provided by IMA.
Conclusions
This paper has set out what Isode plans to do with XMPP. Isode believes
that instant messaging and presence are a logical extension to our messaging
strategy, consistent with our directory and management tool strategies
and has implications for all of our major solution
areas.
XMPP will be the dominant protocol for instant messaging and presence
and Isode's track record in producing secure and scalable solutions,
together with the integration benefits with other Isode products, make
XMPP natural candidate for in-house development.
Feedback on this strategy and input on product requirements are welcome.