Draft and Release is a process of handling formal military communication using a mix of paper and online communication. This paper sets out an approach to online handling of the same communication. It looks at issues with the approaches taken so far to do this, and proposes a new approach and proposed standardization. It then looks at how some of this is implemented in Isode’s Harrier military messaging client described in [Harrier: Military Messaging on Android Devices].

Creative Commons License

Organizational Military Messaging

Military communication has variously been referred to as "Signals", "Formal Messaging" and "High Grade Messaging". In this paper we use the NATO term "Military Messaging" for this type of communication, where messages are sent to an organization (e.g., to a Command) rather than to an individual or to a role.

A key benefit of military messaging is that the sender does not need to understand the internal structure of a receiving organization. However it is clear that, for anything but the smallest organization, there is a risk of creating a bottleneck. This is addressed by including meta-information (such as a Subject Indicator Code "SIC") in the message which enables it to be directed appropriately. Messages received by an organization will be processed by a Profiler, which looks at the SICs and other information in the message and dispatches it to the appropriate recipients.

This process of examination and dispatch is known as draft and release and it is this element of military messaging that this paper focues on, it does not look in detail at other aspects of organizational messaging.

Traditional Draft and Release

The approach for draft and release is set out in the CCEB document ACP121(I), COMMUNICATION INSTRUCTIONS - GENERAL which provides a useful overview of formal military messaging, including use of electronic messaging provided by ACP127 or by STANAG 4406.

The specification defines the layout of a paper form (reproduced below) on which a formal message is written. It is useful to study the form, as it helps in understanding the process.

The person who fills in the form is the "drafter". Once the form is complete, it will be signed by the releasing officer (sometimes referenced as Authorized Releasing Officer (ARO)), someone with appropriate seniority to authorize the message. This authorization is critical, as the ARO is accepting formal responsibility on behalf of the organization. This is important to ensure correct communication and if necessary to take on subsequent legal responsibility.

The completed form is handed to a COMCEN (Communication Centre) operator who will check the authorization and transmit.

Experience with Online Draft and Release

With increasing use of online technology, it clearly makes sense to cut out the paper form and work with a fully online process. It no longer generally makes sense for one person to write the message and another to enter it into a computer. A number of systems and deployments have sought to move the process online, the aproaches used (and the issues those approaches have caused) are outlined below:

  1. Base on workflow: A number of formal military messaging systems have developed around workflow systems or used workflow concepts. This seems natural when concepts such as draft/review/release are considered. A consequence of this is that a structure gets imposed on communications which reduces flexibility. Trying to lock the HGM users into a workflow setup can achieve some of the goals, but does not appear to work well operationally.
  2. Use standard email systems: Another approach is simply to use standard email. Although flexible and easy to use, this lacks necessary capabilities and does not provide the required checks for Military Messaging. It has been observed that is important that users can clearly distinguish between formal Military Messaging and informal email.
  3. Extend standard email systems: There have been attempts to provide Military Messaging by extending standard email systems. One client based approach is to use Microsoft Outlook plugins. This has not worked particularly well for draft and release, and lacks server controls to prevent release by those who are not authorized. It also fails to control sender specification. Another approach operates as an external system to Outlook and Exchange, attempting to layer services over it.
  4. Build a web solution: Building custom Web solutions for Military Messaging, including draft and release, has been a successful approach. These are typically developed as custom front ends to an email back end. This has allowed the system provider to ensure user requirements are addressed (without being constrained by an existing system). A constraint is that all users need to use the same Web system, which is a significant downside.

An ideal solution would draw on aspects of all these general approaches to address service requirements of the older system, use the open standards and distributed deployment of email and provide the flexibility of a Web interface.

Draft and Release Requirements

This section looks at draft and release requirements, as the basis for an online approach.

A central requirement is control of release by ARO (a function traditionally provided by COMCEN). There needs to be certainty that only an approved officer can release a message, noting that the rules associated with this may be complex (e.g., dependent on time of day and message precedence). The ARO is central to the draft and release process.

As part of this, clear audit is vital. There needs to be an audit trail of all Military Messages sent.

Once these goals are met, the primary requirement is flexibility for a range of processes and interactions around the ARO. This needs to recognize that the ARO will typically be a senior officer, and delegation of function will often be appropriate. A range of actions may be useful, and there is no particular need to constrain these. Specific option possibilities:

  1. An ARO may send a Military Message (acting as drafter and releaser). This is a valid approach and the ARO can decide when it is appropriate. This is commonly desired when a junior ARO is authorized to release messages on specific topics at low precedence (e.g., communication of routine engineering requests).
  2. A routine matter may be drafted independently of the ARO, and simply passed to the ARO for approval and release.
  3. The ARO may request someone to draft a message, perhaps because of specialized input or to save the ARO’s time. This person will then pass back the drafted message to the ARO for release. This is particularly likely for a very senior ARO.
  4. There should be flexible review, which might be requested by ARO or drafter, appropriate to the message. Where the drafter has requested review, there should be the option to share this review with the ARO.
  5. There must be control on originator as well as recipients. All external messages need to come from the organization. The actual sender should be clearly audited. There might be a requirement to enable the sender to choose which organization is the originator (if this is the case, ARO rights may vary between the organizations).
  6. There are operational rules for delivery of messages at given precedence and draft/release needs to take this into account.
  7. Release may be transparent. The primary solution outlined here is based on the model that a drafter is aware that they are sending a draft to an ARO. An alternate model is the drafter simply sends the message (as if there was no draft/release process) and the release process is applied where appropriate. Some notes are provided as to how transparent release might be applied after the primary model is described.

There should be audit of the internal process to prepare the message that is released. The internal process of message preparation and review should generally be transparent to the Military Messaging recipients.

A more generic goal is to use open standards. We would like a draft and release approach that can work with a mix of client and server products that support open standards. This seems like desirable flexibility, particularly to allow partner integration and support of mobile devices. We want to allow for a Web interface, but not to require that all Military Messaging users utilize the same Web interface.

A Proposed Approach

This section outlines how draft and release might be provided.

Storing Draft and Release Controls in a Directory

A central part of the design is to use per-user information in the (LDAP/ACP 133) directory to clarify draft and release roles. This information is used in two ways:

  1. By the Message Transfer System (MTS) to provide controls on message release.
  2. By Military Messaging clients to facilitate user actions.

By default a user would not be an ARO. An ARO is identified by attributes that specify that the user is an ARO and constraints on messages that can be released, including:

  • Time of day (e.g., to enable a more junior officer to be ARO “out of hours”).
  • Message Precedence (e.g., to control more tightly release of FLASH and high precedence messages).
  • SICs. This is important as junior staff will be authorized as ARO for specific areas under their control, but not more widely.
  • It may include other things such as Caveats, Rank/Grade, Area of Responsibility (AoR), and Classification (Security Label chosen).

This information will be used by the MTS and is the basis of controls.

This ARO information and other information in the directory may also be used by a participating email client to improve interaction. This could also be achieved by local client configuration, although central administration control would often be desirable. Attributes in the directory can be used to specify the following information:

  • That a recipient is local. This might be done by having a common understanding of the local domain, or a directory attribute could be used to allow a more arbitrary specification of which users are considered to be local.
  • That the client is participating in an HGM system and so all messages will be handled in one or more of the roles of drafter, reviewer or ARO. This would typically be exclusive, but it seems possible that an email client could communicate both HGM and informal messages.
  • ARO status. This is specified above with directory configured information shared with the MTS to specify ARO rights.
  • Drafter status. Typically, most or all users will allowed to be drafters, so this may be defaulted to true. For an HGM participant who is not an ARO, this can enable all messages being prepared to come up as drafts for release by ARO (or for review).
  • Reviewer status. Again, most users will typically be allowed to be reviewers.
  • List of AROs. If a user will use only a single ARO or one from a small set, configuring this in the directory would enable simple and useful UI for ARO selection. A full list of AROs will be obtainable by directory search and this list can be filtered for suitability to release a given draft being prepared. This can provide helpful UI for an organization with a small number of AROs. Transparent release, where the user does not see the ARO (list) is described later.

Defining a directory schema to achieve these functions is straightforward. It may be provided in a later version of this document or standardized as an RFC. This standardization action seems lower priority than the message formats described below and Isode has not so far looked at this.

Message Transfer System Actions

The open standards approach to draft and release uses a Message Transfer System to handle messages.

The server providing message submission can perform a straightforward authorization check. It can ensure that a message is only sent externally when submitted by an appropriate ARO. It can also ensure that other criteria are met, such a message digital signature and inclusion of security label.

This addresses the central ARO authorization requirement.

Message Format Extensions

The basic model of a message being sent to an ARO is that the message to be released is included as a forwarded message. Use of a forwarded message enables the message to be sent by drafter to ARO exactly as it is intended to be submitted; this seems clean and simple. The outer message can then be used to communicate additional information from drafter to ARO, and also additional information (e.g., reviewer comments/approval noted below).

All of the recipients (Action/Information, represented as To/Cc in a MIME message) can be cleanly represented in the forwarded message. This is done with a standard MIME message which is marked by a new header as being "draft for release". The outer message is simply to send the draft to the ARO. The ARO will take the message provided, extract message recipients from the draft, and send the message using appropriate envelope parameters. Envelope information and information in the outer header are used solely to convey information from drafter to ARO, for example the urgency of message release. Priority of the message release is determined from MMHS-Primary-Precedence: in the draft.

Exactly the same model can be provided for message review. Essentially a new "draft for review" forwarded message type.

It is important to recognize responses to review, which will need to be specified as a new format. Responses that need to be conveyed:

  • Draft approved
  • Draft approved with comment (as additional text)
  • Draft not reviewed with optional comment. This is treated as "no objection" but not a formal approval.
  • Draft rejected with comment (which may be additional text, a modified draft, or both). This will typically lead to a review cycle.

The response for review is used for two purposes:

  1. Where there has been a request for review, the review requester will hold the original message pending review. By making review responses clearly identifiable, it will be possible to automate review tracking.
  2. A drafter may include review responses with a "draft for release". This can be done as additional forwarded messages. This will enable the ARO to check message reviews as a part of the release decision.

Review will often be time critical. Use of the Reply-By: field in the outer "draft for review" message will indicated when a message needs to be reviewed by, and the reviewers UI may make use of this. Use of Expires: header can indicate a limit on validity of a draft message. Both of these headers were originally defined in X.400 and are present in the SMTP message due to the MIXER specification (RFC 2156).

There is also a need for formalizing responses to a draft submitted for release. This can be:

  • Message released, with copy of message released. This should only be sent if the drafter requested it. Need a mechanism (MDN request or something new) to allow the drafter to request this.
  • Draft rejected with comment (which may be additional text, a modified draft, or both). This will typically lead to a new drafting cycle.

Protocol Outline

This section looks at how a protocol specification could be put together for the messaging described above. The approach recommended is to use new headers in the outer message. The key advantage of this approach is that the formats used will work (with reduced functionality) with email clients that are not aware of these extensions. Proposed names for new headers are provided.

The first outer header is “Message-Draft:”. A message sent by a drafter to an ARO will have the following structure:

  • The outer header and envelope will be entirely for drafter to ARO communication.
  • “Message-Draft: For Release” in the outer header indicates purpose.
  • The first message/822 MIME object in the message is the draft.
  • Any MIME objects before the draft form part of the drafter to ARO communication. This will typically be a text body part, providing information useful to the ARO.
  • Any MIME objects after the draft form part of the drafter to ARO communication, relating to message review. This will typically be messages from reviewers commenting on or approving the draft.

For draft for review, the same structure is used, but the header is “Message-Draft: For Review”.

Responses to drafts contain information directed back to the draft generator. These responses are correlated to the draft by use of “In-Reply-To:”. This gives unambiguous correlation which will also work for clients not supporting this protocol.

Responses to a draft for release message contain a “Message-Draft:” header using values that show the action taken:

  • Authorized: The message was authorized and sent.
  • Reviewed: The message has been reviewed and approved.
  • Rejected: Draft has been rejected for release or review but not approved. Comments will typically be provided.

Isode has drafted a specification of the format as Implementing Draft & Release and Draft & Review in Internet Mail which has been submitted to the IETF with the intention that it is published as an RFC.

Client Experience

Having described the underlying mechanisms, this section looks at how all this might appear to the user. This also looks at Isode's Harrier implementation. This implements draft and release only. Draft for review will be added in a future release.

Harrier does not use the directory to determine role. Rather Harrier enables the user to configure whether the user is or may be a drafter and choice of ARO. This is shown above, with user choosing to use draft and release always, never or sometimes (optional selected). The list of releasers and option for user specified releasers is also configured. Harrier will act as ARO if any messages are received for release. This approach requires correct Harrier configuration and is independent of MTS enforcement.


When a drafter composes a message, the following fields will appear.

  • Choice of "draft for review" or "draft for release".
  • If "draft for review":
    • The list of reviewers will be manually entered.
    • Review deadline (Reply-By) may be set.
  • If "draft for release", the ARO will be selected (or fixed). The example below shows a fixed releaser included.
  • There will be an option to enter text for the reviewer.
  • All of the normal message fields will be present, to enter into the draft.

Once a draft has been sent, the drafter will be able to see:

  1. List of pending "draft for release"
  2. List of released drafts.
  3. List of drafts for review, with summary review status listed by reviewer.

If a "message released" response comes back, this list should be automatically updated and optionally the drafter informed.

If a "draft rejected" message comes back, this should be shown to the user, and the UI should facilitate re-drafting.

If a review message comes back, the drafter should be shown this. The drafter should have the option to redraft a message (for further review or release) based on the original draft or on a modified draft provided back by the reviewer.


When an ARO composes a message, there will be the option to compose directly for release or to prepare a draft for a different ARO or a draft for review. The ARO is enabled to send messages.

When an ARO received a "draft for release", the message listing shows this. Harrier does this with the "R" in the listing above. When the message is displayed, Harrier indicates clearly that there is a message for release, which can be reviewed by selecting the message. The UI could show any covering notes and attached reviews and enable the ARO to automatically send the draft or edit it and then send (release). The UI should enable “single button” release. The above screen shots illustrate how this is implemented in Harrier, and how the ARO can choose to release or reject a message.


When a message is received for review, the message should be clearly displayed. The reviewer will have a simple "approve/reject" option and ability to type comments. There should also be the option to edit the attached draft and provide a modified/annotated version back with a rejection.

The UI should clearly flag messages pending review response, giving emphasis to those with imminent reply-by times.

An Alternate Approach for Transparent Release

The approach described so far makes the ARO visible to a drafter. An alternate approach is to simply have the drafter send the message as if it is going to the final recipients. The release process is transparent to the drafter and no special capabilities are needed for the drafter email client.

The MTS needs to identify messages that need approval for release, and feed them to an ARO. Two possible mechanisms are noted for this:

  1. Hold the message in the MTA queue. An ARO can review these messages, perhaps with a custom Web interface, and either approve or reject.
  2. The MTS can deliver the message to the ARO, perhaps marked in some way. The ARO can then release the message.

M-Switch implements the first of these approaches. There is an option to hold messages in the M-Switch queue. An ARO (M-Switch operator with appropriate rights) can look at hold messages and release them or reject them. The MConsole GUI for this is shown above. A Web interface to this capability is planned.

Utility for non-Military applications

The message release controls seem fairly specialized, but could be applied in organizations that wish to control external release of messages and not allow all staff to send external messages.

The review processes seem to have general utility in message preparation and review. This could be a useful capability for document review procedures; which Isode plans to support in Harrier.


Traditional paper-based approaches to draft and release are outdated and a number of systems exist which attempt to move the process online. The approaches used for those systems (basing on a workflow system, use of standard/extended email systems and custom web solutions) all have disadvantages which have limited their effectiveness.

Isode’s proposed open standards based draft and release system combines the best elements of workflow, email and web-based systems with capabilities for message review which can be used independent of draft and release. An initial draft of an open standard for a MIME message format has been written to support these functions and an initial implementation in our Harrier client. Further developments are planned in harrier client (both for Android and web) and in Isode management tools (existing GUIs and new web interface).