Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

Isode's Presence, Real Time Messaging and XMPP Strategy

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:

1. Why Presence and Real Time Messaging are important to Isode's customers and markets.
2. Why XMPP, and not another technology.
3. Why Isode is building a product, rather than integrating with available XMPP servers.
4. 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):

1. XMPP messages have a single recipient only.
2. Messages delivery is optimized for clients that are online (i.e., to clients that are connected to their XMPP server).
3. Messages do not have to be stored reliably (e.g., on a disk), so may be dropped if the XMPP server fails.
4. 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:

1. 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.
2. 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.