Military Forms using XMPP

Forms are important for military operations, and there is often a need to handle forms quickly and share with a large number of users. XMPP based open standard instant messaging is widely used by military organizations and is a sensible framework for sharing forms.

Isode has become aware of this requirement for military forms, but the capability described here is generic. There may well be other applications, such as first responder support, where the functionality described here is also useful.

Requirements: MEDEVAC Example

In order to understand the rationale behind this solution, it is useful to understand the nature of the problem being addressed. An important situation in which forms are commonly used is MEDEVAC (Medical Evacuation), following a casualty in the field. The requirements of this example illustrate the nature of the problem being addressed:

• There are many people who need to take actions (from lawyers to helicopter pilots) and many more who need to be informed of the status and evolving plans.
• It is extremely time critical.
• There is a good deal of information to be communicated, and it is critical that information is correct and that nothing is left out. Forms are a good way to handle this.
• People involved may be using different systems – it is generally unrealistic to require all those involved to use a common system.

This paper shows how military forms shared over XMPP can enable effective information sharing.

Forms Display & Publishing: Solution Overview

The solution provided by Form Discovery and Publishing (FDP) as specified in XEP-0346 uses XML forms. The first part of the solution is handling form templates (blank forms) that will be used. The approach for form templates is shown below:

XMPP Publish Subscribe (“PubSub”) uses one or more “PubSub Service”s configured within an XMPP server. A PubSub service will usually be named as a domain. Where a service is being used primarily for forms it might be named as a domain to reflect this, such as “forms.navy.xx”. More information on PubSub is provided in the Isode whitepaper [XMPP PubSub] .

Form templates are identified by topic and every template is held in a PubSub node. The PubSub node is named with a string such as “fdp/templates/topic1”. All FDP templates are identified by the leading string “fdp/templates/”. The rest of the string uniquely identifies the topic. The string may be used to handle complex setups using hierarchy, for example a topic “fdp/templates/forms.navy.xx/medevac/north”, noting that this is a usage convention only as PubSub simply sees these as strings (i.e., there is no hierarchy built into PubSub).

M-Link Console can be used to configure PubSub services, including those used by FDP. M-Link Console can also be used to manage template forms.

A Form Discovery and Publishing (FDP) client uses XMPP PubSub to discover which templates are available, so that the templates can be presented to a user who can select the appropriate form template to be filled in and published as a completed form.

The procedure for publishing completed forms is shown below.

The diagram above shows two FDP clients, one acting as a publisher and the other as a subscriber (note that a single FDP client could act in both roles). An FDP client which has loaded a template can publish a completed form to the appropriate PubSub node, which will hold all of the forms published.

An FDP Client can subscribe to one, several, or all topics. When a new (completed) form is published it will be sent to all subscribers. This enables form distribution to all interested parties.

An FDP subscriber may be an end user, but can also be a gateway that will send the form on to other services.

Published forms are published on the same PubSub service that holds the templates. The “topics” of published forms use the same naming as the templates, so that each template PubSub node is associated with a PubSub node containing published forms. The prefix for published forms is “fdp/submitted/” so forms following the template stored on node “fdp/templates/topic1” are published on node “fdp/submitted/topic1”.

Rationale for the Solution

This section considers the rationale for the various components of the solution described in this paper.

Dynamic Chat Forms

The original concept for the approach here was designed by NATO as a capability called “Dynamic Chat Forms” and implemented in the JChat XMPP client. The FDP protocols are built on this model, and a key FDP goal was to provide the Dynamic Chat Forms capability using an open standard.

XMPP

The open standards based XMPP (eXtensible Message Protocol) is widely used for real time military communication and is a natural base for exchanging forms in a systematic manner.

XML Forms

Use of forms is important to ensure that all necessary data is provided and to avoid errors. It can also facilitate automated or semi-automated processing. Previously, users in the field adopted a pragmatic approach of creating forms in Excel and then pasting the results to XMPP. This approach is not particularly convenient for the user and does not help recipient processing.

XML is a popular representation of structured data, and a natural choice for use with XMPP, which is XML encoded. XMPP has a form definition in XEP-0004 “Data Forms” which is used in XEP-0346.

PubSub

1. Form distribution is achieved using “PubSub” as specified in XEP-0060 “Publish Subscribe”. Information on PubSub is provided in the Isode whitepaper [XMPP PubSub] .
2. The majority of military use of XMPP uses Multi-User Chat (MUC) Rooms. It would be possible to use MUC for sharing XML forms, but PubSub is preferred for two reasons:
3. Although XML forms can be shared over MUC, MUC is usually deployed as a text service. Mixing text messages and XML forms over MUC would cause practical interoperability problems and may confuse users.
4. PubSub allows flexible subscription which gives a client options for access to forms that are not available with MUC.

Gateways

Although XMPP is an important distribution mechanism, there are often other systems that need to submit or receive forms. The PubSub architecture provides a flexible interface for external components to submit (publish) and receive forms as gateway components that integrate with other communications systems.

Product Components

Isode provides a number of components to enable deployment of military forms based on FDP.

M-Link Server Functionality

The M-Link server provides the PubSub and discovery features needed for XEP-0346 and so can be used to support FDP.

Template Management in M-Link Console

Deploying FDP in M-Link involves configuration of one or more FDP domains, and then creating appropriate pubsub nodes to be used for templates and form publishing. M-Link Console can be used to configure domains and pubsub nodes suitable for FDP.

Once the pubsub infrastructure has been configured, M-Link Console is used to upload (i.e. publish) form templates, and to list and display any templates which have already been loaded. Template display is shown in the screenshot above. At the same time as creating the template, the matching pubsub node for storing completed forms is created. M-Link Console ensures that these are managed as a pair.

M-Link Console also manages access control. Each PubSub node has configured access control, specified by domain and/or user. This enables flexible control of:

• Who can update a given template;
  • Who can publish (submit) completed forms of each type;
  • Who can subscribe to receive completed forms of each type.

FDP Clients

Isode has developed a number of prototype clients (which we anticipate will become full products) to help demonstrate and test FDP. The first is the cross-platform desktop “FDP Tool” which is freely available.

This tool enables:

• Listing and retrieving form templates.
• Filling out a form (shown above).
• Publishing a form.
• Subscribing to one or more topics.
• Displaying new and historical forms.

The FDP Tool gives a simple way to access the whole FDP service, which is particularly useful prior to the availability of client products that support FDP. There is a Web interface for publishing and displaying forms shown below:

APIs and SDKs

The Isode M-Link FDP capabilities are being made available in two related APIs:

1. The Swiften C++ API.
2. Sluift, a LUA scripting language API built on Swiften. This is suitable for building test tools and simple applications.

These APIs are available open source and with commercial license and support from Isode. Isode may provide specific extensions to these APIs to help support FDP applications and gateways, perhaps available as a separate software development kit (SDK).

Building simple FDP applications is straightforward. The following code shows a simple gateway from FDP to XMPP 1:1 chat written in two languages. First LUA:

-- Connect
local client = sluift.new_client (botname,botpassword)
client:connect()
 							      
-- Subscribe to the node
local pubsub = client:publish(fdpdomain)
local node = pubsub.node(pubsubnode)
node:subscribe()
 							      
-- Wait for events
node:for_each_event(function(event)
if event._type == 'pubsub_event_items' then
local item = event.item
if item ~= nil then
local message = sluift.to_xml(item)
client:send.message{to=recipientJID,body=message}
end
end
end)
 							      
client:disconnect()

Then C++:

void handleConnected(std::string domain, std::string node) {
auto subscribe = make_shared<PubSubSubscribe>();
subscribe->setJID(client->getJID());
subscribe->setNode(node);
client->getPubSubManager()->createRequest(IQ::Set, domain, subscribe)->send();
}
 							      
void handleIncomingPubSubEvent(const JID& from, shared_ptr<PubSubEventPayLoad> event, std::string recipient) {
auto items = dynamic_pointer_cast<PubSubEventItems>(event)->getItems();
auto message = make_shared<Message>();
message->addPayload(items.front()->getData().front());
message->setTo(recipient);
client->sendMessage(message);
}
 							      
int main(int argc, char ** argv) {
SimpleEventLoop eventLoop;
BoostNetworkFactories networkFactories(&eventLoop);
 							      
client = new Client(argv[1], argv[2], &networkfactories);
client->setAlwaysTrustCertificates();
client->onConnected.connect(bind(&handleConnected, argv[3], argv[4]));
client->getPubSubManager()->onEvent.connect(bind(&handleIncomingPubSubEvent, _1, _2, argv[5]));
client->connect();
eventLoop.run();
 							      
delete client;
return 0;
}

It can be seen that these examples that developing FDP gateways and other applications is straightforward.

Client Plans

Although there are currently no FDP clients (other than FDP Tool and the Isode gateways) we anticipate that clients will be developed to enable full FDP services. In particular:

1. We anticipate that the NATO JChat client illustrated above will be extended to support FDP as the approach to provide the Dynamic Chat Forms service.
2. The free and open source Swift XMPP client, for which Isode offers commercial support will be extended to support FDP.
3. Isode will develop standalone desktop and Android FDP Client products, based on the prototypes described.
4. Isode will develop the Web FDP prototype into a product.

Conclusions

This paper has shown how the new XEP-0346 “Form Discovery and Publishing” protocol can be used to support military forms, and how this might be useful to military and non-military deployments. It has also described current and future capabilities in the Isode product set.