Draft, Review and Release

This whitepaper describes the requirements for military draft and release and how this fits with formal military messaging. The paper then looks at how Isode’s Harrier web based military messaging client supports draft and release, both for military messaging and as a general purpose capability.

A Draft and Release process is important when formal responsibility must be taken for messages sent. Military commands sent as messages will be approved by an appropriate (usually senior) officer performing the Release function. Messages may be drafted by others, leading to the Draft and Release process. This simple workflow can be extended to support message review by others prior to Release.

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 between organizations (e.g., A Ship or a Command) rather than between individuals or roles.

A key benefit of military messaging is that the sender does not need to understand the internal structure of a receiving organization. However, 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 to appropriate Roles to handle the message. 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.

Messages coming from an organization are prepared, reviewed and sent by roles within the organization, co-operating in a workflow called Draft and Release. This workflow is the topic of this whitepaper.

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.

Moving Draft and Release Online

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 makes sense for one person to write the message onto a piece of paper, another person to sign it, and a third to enter it into a computer. This section looks at what changes and what remains the same.

1. In a modern process, everything will happen online. There is no requirement for a printed form or for a COMCEN operator to type in the message.
2. The requirement for the “final sender” to take legal/formal responsibility remains.
3. There are situations where it makes sense to send directly and to avoid any work flow. In particular:
   1. A senior officer needs to send a straightforward message.  No work flow is needed.
   2. A routine message needs to be sent, where there is no requirement for a senior officer to release.
4. There are other situations where a draft and release process is desirable:
   1. A drafter can prepare a message for the senior officer, which the senior office will then approve/release.
   2. The drafter has knowledge/skill to prepare a draft, but it is not appropriate for them to approve for release.
5. Review of messages can be helpful in many situations.

These requirements have been addressed in the Isode product set.

Isode Products

There are two Isode products involved in the Draft/Review/Release process. The first is Harrier, web based military messaging client that provides the capabilities. The second is Cobalt, which is Isode’s provisioning product. Use of Cobalt to support Military Messaging is described in the Isode whitepaper [Provisioning for Military Messaging Handling Systems].

Configuring Draft & Release

Cobalt manages the configuration of Organizations, which will be handled by a Profiler on delivery. For each organisation, Cobalt allows configuration of a set of members, each of which represents an organizational role within that organisation (e.g., “CHIEF ENGINEER”, “FIRE OFFICER”). For Military Messaging, each role is associated with a mailbox, with (human) user assigned to one or more  roles dependent on responsibility. Any role can be occupied by multiple users, for example covering shifts.

A given role may be a member of multiple organizations; when a message is sent by someone occupying such a role, then Harrier will offer the choice of which organization is “sending” the message.

Each member of an organisation is conferred rights that determine what draft and release rights they have (all members can review messages). For a releaser there are two choices of function:

• “Can Draft”. This allows a releaser to also act as drafter.
• “Always Send Directly”. This prevents releaser from acting as a drafter.

Then there are three choices of function for roles that cannot release.

• “Can Draft”. This role can only draft.
• “Always Send Directly”. This role can send any message directly and never drafts.
• “Draft or Send Direct”. This role can always draft and can send messages directly that meet certain (optional) criteria:
  • Priority. Limit’s the highest priority message that can be send directly.
  • Require SICs. Can send directly for a list of SICs. This allows a role to send directly messages on specific topics.
  • Exclude SICs. This allows a role to send directly, unless certain SICs are used. This can be used to exclude use of certain general and sensitive SICs.

The next sections show how these control appear to the Harrier user.

Drafter Selection of Releaser and Approvers

When a Harrier Role with mode “always send directly” composes a message, there will be no change arising from draft and release. However, if the user can draft, options appear as shown in the following screenshot of military message compose.

Notes on the Compose UI relevant to Draft and Release:

1. If the Role is allowed to send from more than one organization, the From can be selected to choose the desired organization.
2. The “Releaser” line will show a list of releases, and the drafter can select which one to use. If the drafter is allowed to send directly, there is also a “No Releaser” option.   This gives the drafter straightforward control of the release process.
3. The “Approver” line allows the drafter to add one or more approvers. Approvers are optional and can be left off, if not desired.
4. The completion action is shown clearly – to send to the first reviewer.
5. Otherwise, the compose screen shows settings and options as if the message was being composed to the final recipients.

Approval and Release

The above screenshot shows the message from previous compose arriving at the first reviewer. The reviewer sees the final message, with a choice of Reject/Approve. Approval passes the message on to the next stage of the workflow. Rejection gives the reviewer the option to provide comments back to the drafter, so that the drafter can correct and resubmit a new draft.

Details of the workflow can be expanded, as shown below.

These details make clear the workflow and where in the process the approval is sitting. It is also possible for those in the workflow to modify the flow. This process continues until the final releaser is reached as shown below.

The releaser is presented the message in a similar way to the reviewer, but with a “Release” button.

Drafter-Centric Parallel Review

The workflow described so far is linear, starting with drafter, going through zero or more reviewers, and ending with the releaser who authorizes sending the message.
This is complemented by a process to allow the drafter to send a draft to one or more reviewers, with responses coming back to the drafter. The drafter can then use information from these reviews to update the draft and then feed a new draft into the linear approval/release process. This approach is sometimes termed “parallel review”.

This review process is initiated by a “Compose for Review” button that will enable the drafter to select a set of reviewers, who will recieve the draft and respond to the drafter.

Use of Standard Encodings

Harrier and the draft and release is implemented using standard SMTP messaging formats, with military extensions as described in the Isode whitepaper [Military Messaging (MMHS) over SMTP]. The headers and other extensions for draft and release are used in a manner that would be straightforward to standardize if desired in the future.

The basic model of a message being sent to a releaser or reviewer 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. 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 releaser or reviewer. The releaser 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 reviewer/releaser, for example the urgency of message release. Priority of the message to be released is determined from MMHS-Primary-Precedence: in the draft.

It is important to recognize responses to review, which are 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:

• 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.
• A drafter may include review responses with a “draft for release”. This can be done as additional forwarded messages. This will enable the releaser 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).

The following responses can be sent from releaser/reviewer to the drafter:

• Message released, with reference to message released.
• Message reviewed, with reference to message reviewed.
• Draft rejected with comment (which may be additional text, a modified draft, or both). This will typically lead to a new drafting cycle.

The headers used are now summarized. The first outer header is “Message-Draft:”. A message sent by a drafter to a releaser or reviewer will have the following structure:

• The outer header and envelope will be entirely for drafter to Releaser/Reviewer 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 Releaser communication. This will typically be a text body part, providing information useful to the Releaser.
• Additional MIME objects can be used as a part of the drafter to Releaser 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:

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

When the message is sent, a Message Delivery Notification (MDN) is sent to the drafter to indicate this.

Isode has drafted a specification of the format as Implementing Draft &Release and Draft& Review in Internet Mail which could submitted to the IETF to be published as an RFC.

Utility for non-Military applications

The message release controls are important for Military Messaging, but could be applied in organizations that wish to control external release of messages and not allow general sending external messages.

The compose for review processes seem to have general utility in message preparation and review., which could be used in any setting.

Conclusions

This paper has shown how Isode’s Draft, Review and Release process is supported by Harrier and managed by Cobalt with an open standards based approach.