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 organisations 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.

The diagram above shows how Topics, each with a Form Template are stored, accessed and managed in an M-Link XMPP server. XMPP Publish Subscribe (“PubSub”) is a general XMPP capability for efficiently sharing information with multiple users.  More information on PubSub is provided in the Isode whitepaper [XMPP PubSub] .

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 the set of forms being supported, such as “forms.navy.xx”. An XMPP server can host multiple PubSub services.

Form templates are identified by topic and every template is held in a PubSub node. The PubSub node holding a topic  is named with a string naming the topic 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).XMPP has a form definition in XEP-0004 “Data Forms” which is used in XEP-0346 to specify forms.

M-Link provides a management interface to managed PubSub domains and FDP topics, as shown above. The template for each topic is configured as part of the topic.

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 above. 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”.

This architecture enables multiple FDP clients to publish forms and multiple FDP clients to subscribe and receive a stream of forms.

NATO Support

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.  NATO have updated JChat client to use FDP.

Gateways & C2

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. This flexibility is particularly important to integrate with Command and Control (C2) systems.

Direct Use of FDP

A simple user use of FDP is to use the service directly and provide a means to submit forms and view a stream of forms. This is how Isode’s initial FDP implementation prototype, shown above worked. It is a simple and viable approach, but now replaced by the capabilities in Swift.

MUC Integration

Isode’s product choice is to integrate FDP with Swift, the Isode general purpose XMPP client; FDP is provided as part of a single XMPP UI and not as a separate tool. The experience, shown at the start of this paper, is to have FDP integrated with MUC (Multi-User Chat).   This has a number of benefits:

1. It starts with an environment familiar to the user, simply adding in forms.
2. There can be multiple forms associated with a MUC room, which can be helpful when multiple forms are used in a command/response scenario.
3. Text chat messages can be interspersed with the forms.

Form publication by Swift is done directly using the FDP protocol.   After submitting a form, Swift publishes a reference to the newly submitted form in the MUC room, visible to all room occupants.  When a MUC user access a MUC room, Swift will use FDP to access the referenced form.

This capability is presented to the MUC room administrator as an option to associate one or more FDP forms (topics) with a room, as show below.

When a Swift user chooses to attach information to a MUC that has FDP forms configured, the use will see an option to submit a form.

This will then lead to a dialogue where the user can choose a form template associated with the MUC room, as shown below.