XMPP Implementation
XMPP Implementation
Overview
This document suggests a mapping of XMPP (Extensible Message and Presence Protocol) Technology onto the associated NHIN Direct Abstract Model. The overarching theme of this mapping is the use of currently existing and widely understood Internet technologies/services/standards.
A XMPP Implementation Development Team is being organized to advance this proposal to a concrete instance. Please join the team if you have expertise, software development skills, and time to contribute. The link to the implementation web page to sign up for development is : XMPP Implementation Team
The XMPP protocol is an open technology for real-time communication, using the XML (Extensible Markup Language) as the base format for exchanging information. XMPP is used in a wide range of applications such as Social networking, VOIP communications, Multi-media conferencing, Instant Messaging, Group chat, Geolocation applications. The XMPP standards and services are defined in two primary specifications published by the Internet Engineering Task Force (IETF) at [1] (RFC series) and in dozens of extension specifications published by the XMPP standards foundation at [2] (XEP series). For more information on the choice of XMPP protocol for healthcare is identified at The Case for XMPP.
NHIN Direct Message
Mime Message carrying different payloads like xml data, documents and binary data wrapped in XMPP xml tags. The Mime Message can be signed and encrypted using PKI infrastructure.
NHIN Direct Source Edge Protocol
XMPP provides flexible options for deployment and can interface with various protocols based on the deployment architecture. The following are the most widely used options for deployment.
XMPP with TLS. (Using standard XMPP ports).
XMPP over HTTP (HTTPS).
NHIN Direct Destination Edge Protocol
XMPP provides flexible options for deployment and can interface with various protocols based on the deployment architecture. The following are the most widely used options for deployment.
XMPP with TLS. (Using standard XMPP ports).
XMPP over HTTP (HTTPS).
NHIN Direct Address
XMPP uses addresses which are similar to email addresses and come in two formats called the short address and the full address. The short address is of the format [[3]]. The full address is of the format [[4]]. For most practical applications the short address is sufficient. The long address will be used when a single entity or person is sending or accessing information from multiple locations. Each location is identified with a resource name so that information can be routed to the different locations based on priority or other routing schemes.
The 'domain" part of the address should be accessible via DNS lookup. For example [[5]] where xmpp.org is resolved using DNS SRV lookups.
NHIN Direct HISP Address Directory
XMPP uses a server federation model for discovering other XMPP servers and domains. The servers, and end points are discovered using DNS directories and DNS SRV lookups. Some XMPP implementations provide optional white listing to allow or deny communication from external servers and domains.
NHIN Direct Backbone Protocol
XMPP over TLS.
Source to HISP
Transaction 1.1: Source authenticates to HISP
- The source and the HISP authenticate with each other using SASL (Simple Authentication and Security Layer) authentication mechanism. The HISP can integrate with existing LDAP directories using XMPP and allow users or organizations to authenticate with the HISP.
Transaction 1.2: Source sends NHIN Direct Message to HISP
- The Source formulates a standard Mime Message wrapped with XMPP message tags. This is done through custom client applications which create, format and send the message using the XMPP protocol.
Transaction 1.3: Source receives message status information
- The source can receive message status on the message by implementing a custom agent on the HISP that responds to all messages with an ACK/NACK status as required.
HISP to HISP
Transaction 2.1: Source HISP authenticates to destination HISP
- The source HISP and the destination HISP can authenticate with each other using SASL authentication mechanisms, along with a white listing of HISP's that are allowed to talk to each other. The protocol that will be used in this implementation is the XMPP protocol with TLS + SASL.
Transaction 2.2: Source HISP sends NHIN Direct Message to destination HISP
- The source HISP determines the destination HISP using DNS lookup and then delivers the message using XMPP protocol.
Transaction 2.3: Source HISP receives message status information from destination HISP
- The source can receive message status on the message sent by implementing a custom agent on the HISP that responds to all messages with an ACK/NACK status as required.
HISP to Destination
Transaction 3.1: Destination authenticates to HISP
- The destination and the HISP authenticate with each other using SASL (Simple Authentication and Security Layer) authentication mechanism. The HISP can integrate with existing LDAP directories using XMPP and allow users or organizations to authenticate with the HISP.
Transaction 3.2 and 3.3: Destination requests and downloads available NHIN Direct Messages from HISP
- The destinatination after authentication receives the offline messages from the server. The server pushes the messages to the user using the XMPP protocol. Optionally the messages can be retrieved from the HISP using the XMPP protocol.
Transaction 3.4: Destination updates message status with the HISP
- The destinatination can send a message indicating the status of the message. This is typically done using a destination application that receives the message content and sends the ACK/NACK back to the source. The destination application would send the message using the XMPP protocol as a reply to the original source.
Other Related Information:
The FHA-CONNECT team is evaluating XMPP as a technology option to implement the NHIN Direct Specifications and Services. The links to the CONNECT resources are listed below: