NATO/EAPC/PfP UNCLASSIFIED

APP-11(C)

APP-11(C)

NATO MESSAGE
CATALOGUE

The information contained in this document shall not

be released to a nation outside NATO without
following procedures contained in C-M(2002)60.

Contents are not to be posted on any freely accessible

information or media facility.

No part of this publication may be reproduced, stored

in a retrieval system, used commercially, adapted, or
transmitted in any form or by any means, electronic,
mechanical, photocopying, recording or otherwise,
without the prior permission of the publisher. With the
exception of commercial sales, this does not apply to
member nations and PfP countries, or NATO
commands and bodies.

I Original
NATO/EAPC/PfP UNCLASSIFIED
NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

INTENTIONALLY BLANK

II Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11 (C)

NORTH ATLANTIC TREATY ORGANISATION

NATO STANDARDIZATION AGENCY (NSA)

NATO LETTER OF PROMULGATION

15 December 2009

1. APP-11(C) - NATO MESSAGE CATALOGUE is a NATO UNCLASIIFIED

publication. The agreement of nations to use this publication is recorded in
STANAG 7149.

2. APP-11 (C) is effective on a date to be promulgated by the NSA. When made

effective it shall supersede APP-11 (8), which shall be destroyed in accordance with the
local procedures for the destruction of documents.

~:::::::~---;lurrrr/if\.f\roRENO
Vic Admiral, ESP(N)
Di ctor, NATO Standardization Agency

III
ORIGINAL
NATO/EAPC/PfP UNCLASSIFIED
NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

INTENTIONALLY BLANK

IV Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

RECORD OF RESERVATIONS

CHAPTER RECORD OF RESERVATIONS BY NATIONS

V Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)
RECORD OF RESERVATIONS

CHAPTER/
RECORD OF RESERVATIONS BY NATIONS
NATION
1. The Bulgarian Armed Forces will not implement the part of the standardization
document concerning biological weapons, because of lack of technical equipment for
BGR biological reconnaissance.
2. Because of lack of appropiate computer system, the Bulgarian Armed Forces will
not implement the part of Chapter IV concerning XML messages.
The ltalian Army will not implement this STANAG because at the moment there is no
ITA plan for the implementation of the whole typology of APP-11 messages in the Army
Automated C2 Systems.
Implementation for human processing of messages: YES
Implementation for aotimated processing of maessages in C2-systems: NO
Remarks:
The messages in the NATO message catalogue will be used when necessary in
combined coalition operations only with messages to be produced and processed by
human operator.
The Netherlands will not introduce any automated C2-system that will accept
NLD formatted messages for automated processing.
The Netherlands will introduce functionally in national C-2 systems that will support
human operators to produce a subset of APP-11 formatted messages. For the land
based domain the exchange of operational information within an international
coalition will be based on the MIP data- and data-exchange standards.
Tor the air and naval domains the exchange of operational information within an
international coalition will mainly be done via NATO systems ICC, MCCIS, Bi-SC AIS
and TDLs.

VI
ORIGINAL
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Reserved for National letter of promulgation

VII Original
NATO/EAPC/PfP UNCLASSIFIED
NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

INTENTIONALLY BLANK

VIII Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

RECORD OF CHANGES

By Whom Entered
Identification of
NATO Effective (Signature; Rank,
Change, Reg. No. Date Entered
Date Grade or Rate;
(if any), and Date
Name of Command)

IX Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

RECORD OF CHANGES

By Whom Entered
Identification of
NATO Effective (Signature; Rank,
Change, Reg. No. Date Entered
Date Grade or Rate;
(if any), and Date
Name of Command)

X Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

TABLE OF CONTENTS
Page No.
CHAPTER 1 - GENERAL INFORMATION
0101. Purpose ............................................................................................................................. 1-1
0102. Scope ................................................................................................................................ 1-1
0103. Definitions ........................................................................................................................ 1-1
0104. Description of APP-11 NATO Message Catalogue ......................................................... 1-2
0105. Roles and Responsibilities................................................................................................ 1-3
0106. Aims and Objectives ........................................................................................................ 1-3
0107. Standards .......................................................................................................................... 1-3
0108. Configuration Management Information .......................................................................... 1-3
CHAPTER 2 – INSTRUCTIONS FOR FORMATTED MESSAGES
0201. Instructions for Use .......................................................................................................... 2-1
0202. Message Instructions ........................................................................................................ 2-2
0203. Set Instructions ................................................................................................................. 2-6
0204. Field Level Instructions .................................................................................................. 2-12
CHAPTER 3 – MTF OPERATIONAL USER GUIDE
0301. Introduction ...................................................................................................................... 3-1
0302. Aim ................................................................................................................................... 3-1
0303. Assumption....................................................................................................................... 3-1
0304. Sections of the Message Text Format (MTF)................................................................... 3-1
0305. How to Read a Message ................................................................................................... 3-1
0306. Decoding a Message ......................................................................................................... 3-2
0307. Using the User Format to Decode a Message................................................................... 3-4
0308. Writing a Message Text Format (MTF) ........................................................................... 3-8
0309. Using the User Format to Write a Message...................................................................... 3-8
0310. Completing the Message. ............................................................................................... 3-16
CHAPTER 4 - XML-MTF
0401. Purpose ............................................................................................................................. 4-1
0402. Introduction to XML ........................................................................................................ 4-1
0403. Examples .......................................................................................................................... 4-2
0404. XML-MTF or MTF? ........................................................................................................ 4-4
0405. Provision of XML-MTF Schemas .................................................................................... 4-4
0406. Best Practice for Systems Implementation ....................................................................... 4-4
CHAPTER 5 - VOICE TEMPLATES
0501. Purpose ............................................................................................................................. 5-1
0502. Scope ................................................................................................................................ 5-1
0503. Responsibility ................................................................................................................... 5-1
0504. Structure ........................................................................................................................... 5-1
0505. Presentation ...................................................................................................................... 5-2
0506. Development .................................................................................................................... 5-2
0507. Configuration Management .............................................................................................. 5-2
0508. List of Voice Templates ................................................................................................... 5-3
CHAPTER 6 - STRUCTURED MESSAGES
0601. Purpose ............................................................................................................................. 6-1
0602. Drafting Instructions for Structured Messages ................................................................. 6-1

XI Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

ANNEX A – MESSAGE TEXT FORMATS

ANNEX B – VOICE MESSAGE TEMPLATES

ANNEX C – STRUCTURED MESSAGES

ANNEX D – NON-COMPLIANT MESSAGES

ANNEX E – FEEDBACK GUIDANCE

ANNEX F – POINTS OF CONTACT

XII Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

CHAPTER 1 - GENERAL INFORMATION

0101. Purpose

The APP-11 NATO Message Catalogue provides users, system developers and Message Text Format
(MTF) managers with a library of messages and instructions for their use. It is a compendium of
formatted messages, structured messages, and voice templates for the exchange of information within
and between Command and Control Organizations. The use of formatted messages as contained in
this catalogue is mandatory for all NATO forces exchanging character-orientated messages.

0102. Scope

1. APP-11 is the definitive source of NATO agreed ADatP-3 formatted messages.

2. APP-11 consists of all approved formatted, selected structured user formats and voice
templates with supporting instructions and data tables.

0103. Definitions

1. Information Exchange Requirements (IER). An IER is a statement of the need to

exchange information between forces or headquarters. It will specify the information to be exchanged
in the context of the mission, key tasks, required degree of interoperability, and parameters of
communication and information systems involved.

2. Change Proposal (CP). A CP is the transformation of the IER into an update of the ADatP-
3 database. It results from consultation between the NATO HQ C3 Staff Information Services Branch
(ISB) and the Message Sponsor, which forms the basis of the updated Message Text Format.

3. Message Formats. In the context of this document, an agreed character orientated data
exchange specification. The 4 types of message specification that are referenced in this publication are:

a. Message Text Format (MTF). MTFs are formatted in accordance with the rules of
ADatP-3 and are designed to be unambiguous and concise in a form that is man-readable and
computer processable. The information to be transmitted in a MTF message is sequentially
ordered and the format must be adhered to.
b. Structured Message Text. A message text composed of paragraphs ordered in a
specific sequence, each paragraph characterised by an identifier and containing information in
free form. It is designed to facilitate manual handling and processing and cannot be processed
consistently by computer based systems.
c. Voice Template. A Voice Template (VT) is a format for voice transmission,
normally based on the information content of an equivalent MTF. It is comprised of a list of
headings against which the user adds relevant information.
d. Non Compliant Message. Identification of the authoritative source of other messages
that are defined in other publications used by NATO forces that do not conform to the rules in
ADatP-3.
4. User Format (UF). The UF is a user-orientated guide to aid the interpretation of a MTF.

5. Extensible Mark-up Language - Message Text Format (XML-MTF). XML-MTF

provides an alternate representation of the traditional character-oriented Message Format. Systems

1-1 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

utilising XML-MTF representation of ADatP-3 message are governed by, and must conform to, the
specifications detailed in ADatP-3 Change 4.

0104. Description of APP-11 NATO Message Catalogue

1. Chapter 1 – General Information. Provides an overview of the NATO Message Catalogue,

its structure, layout and content; states the operational, procedural and technical processes to develop
new or make amendments to existing message formats.

2. Chapter 2 – Message Instructions. Provides instructions for the use of formatted messages
as well as message instructions, set instructions, formatted table instructions and segmentation;
providing understanding to the structure of formatted messages.

3. Chapter 3 – Operational User Guide. Provides instructions on how to read and write a
formatted message at the user level.

4. Chapter 4 – XML-MTF Guide. Provides an insight to ADatP-3 Change 4 XML Schemas,

Style Sheets and their purposes; a basic guide to XML for operators and system developers in the
process of implementing message formats in systems.

5. Chapter 5 – Voice Templates. Provides instructions for the use of Voice Templates.

6. Chapter 6 – Structured Messages. Provides instructions for the use of Structured

Messages that have NOT yet been converted to a formatted message.

7. Annex A – Message Text Formats. MTFs are issued as a Baseline to ADatP-3 database on
an as-needed basis. Appendix 1 to Annex A (A-1) includes hyperlinks to ADatP-3 (current) message
User Formats (UF) and Style Sheets. For operational reasons, MTFs may be updated or created
between baselines. These are issued as a Change to this publication and are temporarily contained in
Appendix 2 to Annex A (A-2). For reference purposes, the previous Baseline is contained in
Appendix 3 to Annex A (A-3).

a. A-1 - current MTFs in Message Title order

- current MTFs in Message Identifier (MSGID) order
- current MTFs by Functional Area
b. A-2 - Operationally required MTFs (new or updated) available for immediate use
c. A-3 - MTFs contained in one previous obsolete Baseline.
8. Annex B – Voice Templates. Provides a list of user Voice Templates (VT).

a. B101 – VTs in Message Title order

b. B102 – VTs in MSGID order
9. Annex C – Structured Message Formats. Provides a list of structured messages that have
not yet been converted to formatted message text.

a. C101 – Formats in Message Title order

b. C102 – Formats in MSGID order
10. Annex D – Non-Compliant Messages. Provides a list of various message/publication titles
not in compliance with ADatP-3 (current) but are required by the operational community. It includes

1-2 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

OTH-Gold messages and NATO publications with embedded non-compliant messages. This Annex
only provides a list of message titles. It does not provide copies of these messages.

11. Annex E – Feedback. Gives instructions on how to provide feedback on APP-11.

12. Annex F – Points of Contact. Provides a list of related web sites and contact details of
associated NATO Working Groups.

0105. Roles and Responsibilities

The Controlling Authority for APP-11 is the Information Exchange Requirement Harmonization
Working Group (IERHWG) which is under the authority of the Military Committee, Joint
Standardization Board (MCJSB). A Nation will hold custodianship for executing document
maintenance. Individual message formats are sponsored by either a NATO Working Group or a
Strategic Command (SC).

0106. Aims and Objectives

1. Formatted Messages. The use of formatted messages in command and control systems has
the following objectives.

a. Enable interoperability by providing data commonality.

b. Reduce the risk of ambiguity and misunderstanding of information.
c. Ensure that messages include essential and consistent data in accordance with agreed
NATO doctrine, tactics and procedures.
d. Reduce the time and effort involved in the drafting, reading and processing of
messages.
(Formatted Messages in APP-11 provide the required operational and technical detail to allow for
exchange of information by automated or manual means).

2. Voice Templates. Chapter 5 gives instructions on how information has to be exchanged

over a voice circuit in a pre-determined structured order. This is essential to ensure consistency in the
use of each message, whatever its means of transmission, and reduces the risk of ambiguity,
misunderstanding or omission of essential information detail.

3. Structured Messages. Structured messages as contained in the catalogue will be superseded

by formatted messages in the future. Until then, Chapter 6 provides general instructions for their use.

0107. Standards

In accordance with the STANAG 2211 (Geodetic Datum’s, Projections, Grids and Grid References),
the mandated geodetic datum to be used in NATO operations shall be World Geodetic System 1984.
Where, for operational reasons this is not possible the geodetic transformation to be applied to
locations in a message is to be included with the message. Where no geodetic datum transformation
information is included in a message, the positions are to be converted to World Geodetic System
1984 before message transmission.

0108. Configuration Management Information

1. Under the cover of STANAG 7149, APP-11 will be managed using the procedures detailed
in AAP-3. Whilst APP-11 is under the configuration control of the IERHWG, the content of Annex A

1-3 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

is technically managed and agreed by nations under the procedures for managing message text formats
prior to inclusion into APP-11. Due to the higher level of scrutiny given to the content of proposed
changes to Annex A, the normal process for changes to this Annex will normally use the urgent
ratification procedure outlined in para 0109 of AAP-3 (Directive for the Development and Production
of NATO Standardization Agreements (STANAGs) and Allied Publications). Ideally, national
representatives at the IERHWG will be able to indicate the ratification position for changes that will
be taken by their national delegation to the MC JSB. Nations not wishing to implement a particular
message or express other reservations can do so during this process. Chapters and the remaining
Annexes will use the normal ratification process. Once APP-11 receives sufficient positive ratification
responses, and the MC JSB considers that the promulgation criteria have been achieved, the document
is promulgated by the Director NATO Standardization Agency (NSA). The NATO Effective Date
(NED) is established based on recommendation of the IERHWG.

2. The Single Service Standardization Boards nominate the Message Formats to be included in
their functional areas listed within the Annexes of APP-11. The IERHWG is ultimately responsible
for determining the Message Formats to be included within the Annexes. All Message Text Formats
included in APP-11 must be from the agreed portion of the ADatP-3 database.

3. Requests for the development of new messages or changes to current messages as laid down
in the Annexes are to be submitted via the national Chain of Command to the sponsoring NATO
Working Group. These changes are to be submitted using the Information Exchange Requirements
(IER) instructions located in NATO Standardization Agency Procedures (NSAP) Vol II.

4. All UFs contained in APP-11, Annex A have been developed in consultation with the NATO
Information Services Branch (ISB) Staff in conformance with ADatP-3. Any changes made by ISB
must be technically approved through the Message Text Format Working Group (MTFWG). The
release of this technically complete work will be agreed by the MC JSB based on recommendations of
the IERHWG.

5. Nations/SCs proposing changes to the content of this publication are to ensure that proposals
are addressed to the appropriate authority in accordance with Annex E.

1-4 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

CHAPTER 2 - INSTRUCTIONS FOR FORMATTED MESSAGES

0201. Instructions for Use

1. General. The formatted messages in this publication are designed in accordance with the
NATO Message Text Formatting System (FORMETS), described in ADatP-3, and covered by
STANAG 5500. This system is designed for the exchange of character oriented information in a
format that can be processed both manually and by computers. It has the following objectives.

a. To improve interoperability between different national and NATO authorities and

systems.
b. To provide the rules, constructions and vocabulary for standardized character-oriented
Message Text Formats (MTF) that can be used in both manual and computer-assisted
operational environments.
c. To ensure that messages include essential data and to reduce the risk of
misunderstanding.
2. Purpose. This Chapter contains detailed information on formatted message construction.
This section sets out the general and special information required by an operator writing, processing,
and reading formatted messages. Information and instructions specified to an individual message or
set are contained on the appropriate pages. Annotated examples on reading and writing formatted
messages are contained in Chapter 3.

3. Concept. A formatted message is defined in a simple language suitable for the exchange of
character oriented information. The system comprises the rules governing representation of agreed
conceptual definitions and arrangement of these representations within predetermined formats. The
application of FORMETS rules of information exchange requirements results in an open-ended
inventory of agreed representations, i.e. Field Formats, Set Formats and Message Formats, which is
designed in accordance with a defined set of rules to produce a formal structure.

4. Format Structure. Formatted messages have a formal structure, which must be followed
according to the rules set out in this Chapter, Figure 2-1 shows the relationship between the major
component of an MTF, solid lines are relationships that must exist, dashed lines are relationships that
may exist depending on the design of the message. Every formatted message is generated from an
Information Exchange Requirement (IER). IERs specify the information to be exchanged in a
standardized manner within the context of the mission. They describe key tasks, required degree of
interoperability, and the parameters of communications and information systems involved. The order
of all components (i.e. sets, segments, fields) in a message is predefined in the format and are referred
as format positions.

Message

Set Segment

Field

Figure 2-1 - Message Structure

2-1 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

0202. Message Instructions

1. Message Text Composition. The content of a formatted message is an ordered collection

subdivided into 'Sets' each covering a specific aspect of the message. Sets within a message can be
grouped together to form segments and one segment may be nested within another segment.

2. Message Formats. A Message Format has a unique Message Text Format Identifier
(MTFID) and specified sequence of sets and segments. The unique MTFID is a mnemonic keyword
that associates the type of information that is to be provided by the message. It is contained in the
message identification set (MSGID) which is at the beginning of each message. It also identifies the
sets allowed by the message text format and the order in which they must be arranged.

a. Set Formats with identifiers EXER, OPER, MSGID, and REF occupy the first set
format positions in each Message Format. Of these Set format identifiers only MSGID is
mandatory and must be specified in each Message Format.
b. The subsequent set format positions of the Message Format have been assigned as
needed to satisfy a particular information requirement.
3. Occurrence Categories. Each set and segment in a formatted message is assigned an
occurrence category, based on the importance and logical relevance to the information to be conveyed.
The occurrence categories are also used in the field format positions within a set format. There are
three types of occurrence categories:

a. Mandatory (M). Format positions that provide information considered essential to

the message are assigned a “Mandatory” occurrence category and must be filled in.
b. Operationally Determined (O). Format positions whose use is determined solely by
operator considerations are assigned an occurrence category of “Operationally Determined”.
This format position may or may not be filled in depending on the operational requirement and
availability of information.
c. Conditional (C). Format positions whose use is dependent upon a defined condition
are assigned an occurrence category of “Conditional”.
4. Message Introduction. An example of the introduction page for a message is shown in,
with the following keys:

[1] The Message Identifier, as used in the MSGID set.

[2] Full name of message.
[3] Related Documents.
[4] Brief summary of purpose of the message.
[5] Sponsor of the message format.
[6] Explanatory notes about the message format.
[7] Administrative status of the message format.
[8] Publication Name, Message Reference Number, Version Number.

2-2 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Figure 2-2 - Message Introduction

5. Message Map. The Message Map follows the Message Introduction. The following figures
identify features of this format.

The message map is divided up into 8 columns, the content of which is discussed later
in this section. The column details are:

Seg - Used to indicate the grouping of sets in segments (see

para 0202.7).
Alt - Used to indicate alternative set use (see para 0202.11).
Rpt - Used to indicate repeatability of sets (see
para 0202.16).
Occ - Occurrence category of set (see para 0202.3).
SETID - Used to identify the name of the Set. (see para 0203.2).
Seq - The sequence number of the set.
Set Format Name - The name of the set (For GENTEXT sets, this is the
content of field 1) (See para 0203.17.d)
Description - Provides a brief description of the information

Figure 2-3 - Message Map – Part 1

6. Interspersed through the message are a number of rules. In Figure 2-3 after Set 3 (MSGID)
there is a rule stating that “FIELD 1 IN SET 3 (MSGID) IS ASSIGNED THE VALUE /OPTASK

2-3 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

LINK/”. These rules must be complied with to ensure the validity of a message. As well as rules
assigning values, other rules prohibit or require certain information depending on another component
in the message.

7. Segmentation. Two or more sequential Set format positions in a Message format that are
related by their content can be designated as a segment structure. Instances corresponding to such a
segment structure may occur as many times as needed within a message format. Normally there is no
limit to the number of times a segment can be repeated within an instance of a message; however, in
some messages, the number of repetitions of a segment may be restricted in the message design. Any
restrictions are included at the end of the segment start line. By specifying a limit of only one
occurrence, a non-repeatable segment can be present in a message.

8. Where segments occur in a message, additional information is available about how they are
to be used. Each segment is given a number and if it contains another (nested) segment, the segment
number is extended using dot notation. Figure 2-4, shows an example of the start of a segment and
supporting information about how it should be used. Note that the segment number, 3.1 is shown
against each set in the segment At the end of each segment there is a statement to inform the message
drafter that they have reached the end of the segment e.g. “[3.1] End of FRIENDLY CONTACT
DETAILS SEGMENT”.

Figure 2-4 - Message Map – Part 2

9. Segment structures can be nested to whatever extent is required, Figure 2-5. Segments are
identified in the message map through the use of numbers in the “Seg” column. E.g. the first segment
in the example is numbered 2.1. The first segment nested within the segment is 2.1.1 a second nested
segment would be numbered 2.1.2 and so on.

Figure 2-5 - Message Map – Part 3

10. The initial Set of a segment may be selected from two or more mutually exclusive Set format
positions where one is required. This concept is explained in para 0202.11.

11. Alternatives. Adjacent sets/segments may have an inter-dependence on one another that
prohibit one if another is used. The allowed conditions for alternative sets are:

2-4 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

a. The sets/segments are mutually exclusive but one is required, i.e. only one of the
alternatives must be selected. Only a number is shown. See para 0202.13
b. The sets/segments are mutually exclusive but none are required, i.e. only one of the
alternatives may be selected. A number and the “#” character, see para 0202.14.
c. At least one of the alternatives is required but more than one can be used, i.e. one or
more alternatives must be selected. A number and the “*” character, see para 0202.15.
12. In the message map alternatives sets/segments are identified by the same number being used
in the “Alt” column. i.e. all sets/segments that are alternatives will have the same number against them.
In order to identify which kind of alternative is to be used, an additional character may be added after
the number.

13. If only the number is shown in the column, only one of the sets/segments with the same
number against it must be used at that position in an instance of a message. Figure 2-6 is an example
taken from a message. Sets 17 (RADARC), 18 (POLYGON) and 19 (CIRCLE) can all be used in the
message but the message drafter must only select one of the sets to be used at that position in the
message. Of course, if the segment 1.1 is repeated, where it is allowed in the message, the message
drafter can make the choice of the alternative again.

Figure 2-6 - Alternate example, one required annotation

14. If # follows the number, e.g. 1#, in the Alt column then either 0 or 1 of the alternatives may
be selected. In Figure 2-7 sets 1 (EXER) and 2 (OPER) cannot be used together in the same message;
however, there is no requirement to include either of these sets in an instance of the message.

Figure 2-7 - Alternate example, non-required annotation

15. If * follows the number, e.g. 3*, in the Alt column then one of the alternatives must be
included in an instance of a message but it is permissible to use more than one of the alternatives. It
should be noted that the order that the sets appear in an instance of a message must be the same as the
order that they appear in the message map.

16. Repetition. In the Message Map sets may be identified as being repeatable. In an instance of
a message, the repeated set must immediately follow the original set. Sets that may be repeated can be
identified by a 9 in the Rpt column. E.g. in Figure 2-8 set 4 (REF) can be repeated as many times as
required.

Figure 2-8 - Repeatable set

2-5 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

17. In some messages a maximum number of repetitions of the set may have been specified. In
this case, the 9 mark will be followed by a number, e.g. 94 which should be interpreted as the set
being repeatable up to 4 times.

18. There are a number of set types that cannot be repeated and should not appear in the message
map as being repeatable. These are:

a. The initial Set format position of a segment, this includes alternative initial sets.
b. Scheduled freetext sets (GENTEXT)
c. Additionally, unscheduled freetext AMPN, NARR and RMKS cannot be repeated as
adjacent locations sets in an instance of a message. E.g. the construction in Example 2-1 is not
legal.
AMPN/Amplification 1//
AMPN/Amplification 2//
Example 2-1 - Example of illegal unscheduled freetext repetition

0203. Set Instructions

1. Definition of a Set. A set is a component of a formatted message covering one specific

aspect of the message subject. Sets are made up of one or more fields which contain the data. There
are two types of sets; Linear where all the fields are in sequential order and Columnar sets where the
fields are presented in the form of a table. Sets must start with a Set Identifier (SETID) which gives an
indication of the content, as well as providing the identification of the set format used, e.g. the REF set
contains information about references.

2. SETIDs. The SETID is a unique group of characters assigned to each set format as a key to
the structure and information content of that format. The SETID for each set in the message is shown
in the 5th column of the message map, see Figure 2-3. In electronic copies of the publication the
SETID in the message map is also a hyperlink to the set format page. The SETID is not referred to in
the field count i.e. Field 1 is the first field after the SETID.

3. The set format page provides the detailed layout of the set. A Set map for a linear set is
shown in Figure 2-9; the map provides the order in which the fields in the set appear. Like sets, each
of the field positions have an occurrence category, marked as M, C and O on the set map, with the
same meanings as detailed in section 0202.3.

4. The minimum and maximum permitted length of the field is shown as a range on the set map.
Note that if the set map extends onto a second line, the SETID is included, this should not appear
when writing a message, eg in Figure 2-9 the “Location” Field should immediately follow the “Area
Geometry” Field.

Figure 2-9 - Linear set map.

2-6 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

5. Repetition within Linear Set. In the linear set, the designated final field, or group of
contiguous fields that includes the final field, may be repeated.

6. If there are a group of fields that can be repeated at the end of the set the word
“REPEATABLE” is shown underneath the field group. When repeating fields, all the fields in the
previous repetition must be completed irrespective of their occurrence category.

7. Below the set map is a detailed explanation of the information that can be placed into each
field. An example is in Figure 2-10.

Figure 2-10 - Set filler notes.

8. The set filler notes identify the fields in sequential order. The majority of fields have a single
format for the information that can be included in the field; however fields such as Field 2 in the
example can have more than one format. These are known as alternative content fields.

9. Repetition within Columnar Set. All the fields of a columnar set comprise of a repeatable
group of fields. In columnar sets, each instance of the group of fields is always entered on a new line
in order to maintain the desired tabular arrangement.

10. The set map for a columnar set, Figure 2-11 is similar to a linear set with an additional 2
rows of information for each field, these are:

a. column header
b. the start column and justification (Left or Right).

Figure 2-11 - Columnar set map.

2-7 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

11. Alternative Content Fields. Some types of information can be expressed in a variety of
ways. For example, Location can be stated as geographic coordinates, bearing and range, place name,
etc. The Set format may specify two or more mutually exclusive alternative field formats for the same
field format position of a linear or columnar set format. These fields are known as Alternative Content
Fields. In these cases a field descriptor may be used to assist the reader in determining the information
used. E.g. in Figure 2-10, Alt B of field 2 has the field descriptor “TYPE”.

Note: A field descriptor is always separated from the field content by a colon (systems may
automatically insert this character).

12. To the right of the table is an explanatory note about the field and how it should be used.
There is an example of the format that the information should be entered in and a link to a table which
details the exact information that may be entered into the field.

13. After the set filler notes there is additional information that may assist with the interpretation
of the set, these are:

a. Notes and special instructions that are applicable to the set.

b. Documents that are related to the set and may provide further guidance as to how it
should be used.
c. At least one example of a completed set.
d. Rules that are specifically associated with the set can be found at the final entry on the
set format page. These have a similar function as the message level rules described in
para 0202.6 but are only applicable to the content of the set.

Figure 2-12 - Amplifying information in the set format

14. Rules for the Construction of a Set. In order to provide both manual and automated
readability of a formatted message, a number of syntax rules must be obeyed for the completion of
each set.

a. All Sets must start at the beginning of a line with the SETID.
b. All Sets must have at least 1 field completed.
c. Each field in each Set must begin with a field marker (/).
d. With the exception of the free-text field in the GENTEXT, AMPN, NARR and RMKS
sets, a field must not be split between lines.
e. The end of each Set must be indicated by the end-of-set marker – double slash (//).
The // characters must not be split between lines. If this is likely to occur on the
communication system being used then a line feed should be inserted to create a continuation
line that only contains the end-of-set marker. See Example 2-2.

2-8 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

COMMS/CTF40/ABC/333.3MHZ/P/VOICE/222.2MHZ/S/VOICE/S/303.0MHZ
//
Example 2-2 - A linear set where the end of set marker extends over the line

f. Appropriate unscheduled free text sets may be inserted between sets in the message
map, but they must not interrupt a set.
15. Linear Sets. A Linear Set is constructed so that fields are arranged in a linear manner. A
linear Set format may contain as many field format positions as are necessary to satisfy the
information exchange requirements addressed by the Set.

a. A Linear Set format identifier uniquely eg JUDATA in Example 2-3..

b. The meaning of the contents of the fields of a linear set is established during the
design of the set by specifying the type of information to be provided in each field position.
The fixed relationship between field position and context meaning makes it essential that the
order of fields be maintained in all applications of a given set.
c. Theoretically, a linear set should appear on a single line of infinite length; however, in
most transmission mediums it will be necessary to split a set with several fields onto more
than one line, in this case the line feed should be inserted at the end of the field so that the new
line starts with a new field marker. See Example 2-3.
JUDATA/SHIP:NIMITZ/CS:STONEWALL/JU:00001/16/00277-00300
/BLOCK:00201-00500/-/SHIP-3/12/NORM/1000/PRI/Y/-/-
/FBLOCK:00300-00500//
Example 2-3 - A linear set extending over more than one line

d. The final field format position or Group of Field Formats in a linear Set format may
be designated as being repeatable.
16. Columnar Sets. Set formats designed for columnar presentation allow repetitive
information to be arranged in vertically aligned columns under an appropriate column
header, Example 2-4. The fields of a columnar set often contain, as part of the field content, blank
characters that are required to achieve the columnar presentation.

a. The SETID for columnar sets always begins with a numeric character, The SETID for
a columnar set is entered alone on the first line of a columnar set. Eg 1AMMOH in Example
2-4
b. The second line of a columnar set comprises the header line, which may occur only
once. It contains column headers, blank characters and slashes (/) as column delimiters, all of
which are specified by the Set format. Column headers provide a cue to the human reader as
to the type of information contained in each column, and are required irrespective of the
occurrence categories assigned to the corresponding field positions by the columnar Set format.
The column headers are always justified to the left irrespective of the justification specified for
the contents.
c. Columnar sets make use of the convention for grouping fields to allow for their
repetition as a group. After the header line each subsequent line of a columnar set is made up
of a group of fields. All of the fields that are specified for the Set must be included in this
group. The specification of column position, column header and maximum field position
length of the last column in a columnar Set format must be such that, the header line and lines
of group of fields are limited to a maximum of 69 character-positions. Each instance of the
group of fields is entered on a separate line beginning at the first character position of the line.

2-9 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

d. Blank characters are added as part of the field content to maintain the columnar
alignment.
e. Each field is fixed in length and contains sufficient character positions for the entry of
either the field marker, the field descriptor and the longest code permitted by the assigned data
codes or the column delimiter and column header, whichever is greater.
f. Data codes are left or right justified within the field according to specifications given
in the Set map.
g. The end-of-set marker (//) is positioned immediately after the final data code of the
last iteration of the group of fields; however, it shall be placed on the next line if the final data
code plus the end-of-set marker exceeds the 69 character line length.
1AMMOH
/CODE /AMMO-NAME /QTY-OH /DOS
/AMMO50 /50CAL / 3000/2
/HOW105 /105MM / -/2//
Example 2-4 - Columnar Set

17. Free Text Sets. Free Text sets begin with a SETID and are terminated with an end-of-set
marker (//). A Free Text Set contains a free text field of unrestricted length, which is arranged in
contiguous lines. The information conveyed in the free text field of Free Text Sets usually contains
natural language and may make use of all available characters. Additionally the 4 free text sets have a
number of special rules that are unique to them. Normally the slash character (/) and the colon (:) are
reserved for special use in sets; however, the following deviations from this general rules are
permissible in the free text field.

a. A colon may be used but not as the last character of the free text field.
b. Single slash character may be used provided it is not the first or last character of the
free text field.
c. Two slash characters may not be used adjacent to each other, other than to mark the
end of the set, unless they are proceeded by a colon, i.e. ( :// )
GENTEXT/SPECIAL INFORMATION/This is an example of how the colon and
two slashes can be used within the free text field.
http://www.nato.int providing information that previously had to be
spelled out.//
Example 2-5 - The use of :// in a free text field of a free text set.

d. There are four Free Text Set Formats. One (GENTEXT) appears in the Message Map
and the others (AMPN, NARR and RMKS) are unscheduled and may be inserted at specific
positions in a message.
(1) GENTEXT Set – (General Text). This set contains two fields; the first field
provides the description of the subject and is followed by a free text field with no
prescribed length limitation. The content of field 1 is predefined and a rule will always
follow each GENTEXT set in the message map e.g. “FIELD 1 IN SET 140
(GENTEXT) IS ASSIGNED THE VALUE /SPECIAL INSTRUCTIONS/.” The value
given must be entered exactly as written in the rule.

2-10 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

GENTEXT/SPECIAL INSTRUCTIONS/1. CAPACITY:MDM TK, 50 VEHICLE CONVOY.

2. CHOKE POINTS:EXIT 5, TANTA, AND ALEXANDRIA.
3. DAMAGE: LARGE POT HOLES 10 KM SOUTH OF TANTA.
4. NO ENEMY ACTIVITY//
Example 2-6 - Use of GENTEXT

(2) The AMPN, NARR and RMKS sets – Amplification, Narrative, and
Remarks. These sets contain only a single free text field and are for unscheduled use.
These sets are not repeatable. A message text may not contain successive AMPN or
NARR sets and only one RMKS set may be used as the very last set of the message.

(a) AMPN set is used to provide an explanation or additional information

concerning only the preceding set.

(b) NARR set is used to provide an explanation or additional information

concerning an immediately preceding group of two or more adjoining sets.
The sets that the NARR set is referring to should be able to be identified
through the content of the free text. A NARR set could commonly be used to
provide a free text explanation about a group of sets in a segment.

(c) RMKS set is used to provide an explanation or additional information

applicable to the whole message text. When used, it will always be the last
set of the message text.

(3) Depending on the structural relationships of the required free text information,
it is possible for an AMPN set to be immediately followed by a NARR or the RMKS
set, or for a NARR set to be immediately followed by the RMKS set. The AMPN set
cannot immediately follow the NARR or GENTEXT set.

(4) Unscheduled free text can only be used between sets, for instance, in a
columnar set with four lines, explanatory information regarding data in the third line
would be entered in a Free text such as in the AMPN set, positioned immediately after
the completed columnar set and not between the lines in the columnar set,
see Example 2-7.

1AMMOH
/CODE /AMMO-NAME /QTY-OH /DOS
/AMMO50 /50CAL / 3000/2
/HOW105 /105MM / 500/2//
AMPN/NO CHANGE TO HOLDING OF 50CAL IN LAST 24 HOURS//
Example 2-7 - Use of AMPN in Columnar Set

18. Truncation of Sets. Truncation of a set by omission of one or more fields is permitted as
follows:

a. Unused fields (fields with single hyphen as content) at the end of a set with
operationally determined or conditional occurrence category may be omitted.
b. Unused fields with operationally determined or conditional occurrence category at the
end of a group of fields in a columnar set may be omitted. Example below shows in line 2
with the last two fields omitted and in line 3 with the last field omitted.

2-11 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

2PAX
/PAX /TOTWGT /EMBARK /DEBARK /PREFDEL/R/HEL
/ 2/ 110KG/N:GARMISCH /N:BRUSSELS /PARAHIG/N/ 1
/ 2/ 120KG/N:BRUSSELS /N:KOLN /LANDNRQ
/ 3/ 115KG/N:KOLN /N:KOBLENZ /PARGULL/Y//
Example 2-8 - Truncation of a Columnar Sets

0204. Field Level Instructions

1. Definition of a Field. A field is a subdivision of a set which contains data items, a chain of
linked data items, or free text. The message map and set instructions guide the originator and the
recipient to the position of the entry, but the actual data is contained in the field.

2. Field Formats. There are 2 types of field formats, elemental or composite. These types and
their relationships are described below.

a. Elemental Field Format. The content of an elemental field relates to a single piece
of data e.g. the month of the year. The types of data that an Elemental Field can contain is
covered in Para 0204.3 below.
b. Composite Field Format. Is composed of a sequence of elemental fields in a specific
order. E.g. a Date time group is composed of the elementals Day of the month, Hour, Minute,
Time zone, Month and Year. These elementals are combined to form a single field.
3. Types of Elemental Field Formats. Elemental field formats fall into 3 types, data codes,
range entries and instructive entries:

a. Data Codes. Words in natural language are not always suited for use in formatted
messages and are usually represented either by abbreviations or by codes already in existence
in publications. In the UF, list of coded items are shown in table specifying the list of
individual data items and data codes where each entry has a specific meaning, Figure 2-13.
Data codes are the legal values permitted in a field. Each of the Data Items may have an
explanation associated with it to ensure that a clear definition is provided where necessary.

Figure 2-13 - Coded Items

b. Range Entry Type. Specifies a range of data items and data codes, there are 3
different types of range entries.
(1) Integer Ranges. An integer range is specified using the minimum integer
value and the maximum inclusive integer value of the range with intermediate values
understood to be whole numbers. Allowed characters for integer range are the
characters "0" through "9" and the character "-" to express negative values.

2-12 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

(2) An integer range is specified as either fixed or variable length, if the length is
fixed, leading 0 characters should be added. Figure 2-14 shows how an Integer Range
is represented in the User Format.

Figure 2-14 - Integer Range Table

(3) Ranges Containing Decimal Point Values. A decimal range is specified

using the minimum value and the maximum value of the decimal range. A decimal
range specifies either a fixed or a variable number of decimal places (digits to the right
of the decimal point).

(4) A fixed number decimal place specification indicates that all values contain
the same number of decimal places. A variable number of decimal places specifies the
minimum and maximum value over which the number of decimal places may vary.
Values without decimal point are only allowed when the minimum range of decimal
places is zero.

(5) Allowed characters for decimal range are the same as for integer range and
the decimal point character ".". Figure 2-15 shows how a Decimal Range is
represented in the User Format.

Figure 2-15 - Decimal Range Table

(6) Alphabetic and Alpha-numeric Ranges. An alpha-numeric range is used to

specify a range of values that contain all alphabetic characters, a mixture of alphabetic
and numeric characters, purely numerical ranges where the interval is not one and
complex ranges expressed as regular expressions. The explanation of how this is
achieved mathematically in ADatP-3 is beyond the scope of this publication. In order
for operators be able to interpret the requirements for a message, the ranges of data
items available have been expressed in a format similar to Figure 2-16. Care must be
taken to ensure that the value chosen can be derived by looking at the 1st, 2nd and last
value, particularly when the second value is incremented by a value other than 1, e.g.
in Figure 2-16 the 1st value is 000, the 2nd value is 005 and the final last value is 990,
only values that are incremented by 5 are permitted.

Figure 2-16 – Alpha-numeric Range Table

2-13 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

(7) Regular Expressions. A method of specifying complex Alpha-numeric

Ranges is the UF is known as a Regular Expression. These cannot be defined in
simple terms in a table. Where these mathematical expressions appear in the UF a
plain language explanation is also provided, Figure 2-17.

Figure 2-17 – A Regular Expression Table

c. Instructive Entry Type. In this type of entry, data items are not specified; however,
allowable characters and a maximum and minimum length are specified.
(1) There are normally 3 instances where this type may be used:

(a) Fields that are to contain text, the exact wording of which cannot be
anticipated.

(b) Those exceptional cases when the volatility of individual entries or

ranges is such that the standard cannot be updated in time to reflect the
operational needs.

(c) Individual entries or ranges would result in a classification of the

ADatP-3 format repository that is higher than acceptable at the time of
specification.

(2) In Figure 2-18 the number of characters permitted are between 1 and 15 and
must be Alphabetic Upper Case (A-Z), Blank, Numeric (0-9), Special characters.
There may be additional information in the explanation.

Figure 2-18 - Instructive Entry

(3) Field Contents. Field content of an instructive entry is divided into 6 general
groups these are:

(a) Alphabetic Upper Case Characters:

ABCDEFGHIJKLMNOPQRSTUVWXYZ

(b) Alphabetic Lower Case Characters:

abcdefghijklmnopqrstuvwxyz

(c) Blank Characters

(d) Numeric Characters

1234567890

2-14 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

(e) Special Characters

.,-()?

(f) Extended Special Characters

!@#$%^&*=_+[]{}\"';<>~|

(4) The free text field of the GENTEXT, AMPN, NARR and RMKS sets can also
contain:

(a) Free Text Special Character

:// The colon double slash character sequence.

(b) Slash Character

/ The single slash character.

(c) Colon Character

: The colon character may be used on its own in a freetext set but may not
immediately precede the end of set marker “//” which could cause confusion
with para 0204.3.c(4)(a).

(d) Line Separator

The sequence of control characters carriage return and line feed necessary to
begin a new line.

(e) Horizontal Tab

4. The Use of the Hyphen "-". There are several uses for the hyphen as described below.

a. Data Not Available or Being Withheld. When the data needed to complete a field is
not available or is being withheld, the Hyphen "-" is used as the field content.

(1) The use of a Hyphen may only be used once in a field irrespective of whether
it is an elemental or a composite. In the case of a composite if one of the elements of
the composite are not available or being withheld the whole field should be considered
to be not available and a single hyphen should be inserted in the field. A field
descriptor cannot be used in conjunction with a hyphen.

(2) If a Composite Field is specified, all elements of a composite field format

must be known in order for it to be completed. As an example, Table 2000 (Day and
Time) is a composite field format composed of elemental Tables 1000 (Day), 1001
(Hours), 1002 (Minutes) and 1003 (Time Zone). If the correct time zone is not known,
Table 2000 is not known, in its entirety, and the hyphen must be used.

b. Linear Sets
(1) When the data needed to complete a field within a linear set is not available or
being withheld, the hyphen will be entered immediately following the associated field
marker. The hyphen will be followed immediately by either the next field in the set, or
the end-of-set marker.

(2) At least one field in each repetition of a group of fields shall contain a data
code. It is not permissible to place a hyphen in all the fields in the field group.

2-15 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

c. Columnar Sets. Hyphens are entered in the fields of columnar sets when
corresponding data is not available for those fields.
d. Inappropriate Data. The hyphen is also used to complete a field when entry of a
data code would be inappropriate. This situation could arise when there is a rule that prevents
one field being used when another one is. E.g. “FIELD 1 IN SET ^ (MODE) IS REQUIRED
IF FIELD 2 IN SET ^ (MODE) DOES NOT OCCUR. ”. In this case the requirement for
Fields 1 is dependant on Field 2 having data in it. To maintain the structure of the set
(para 0203.15.b) a hyphen must be placed in the field that cannot be completed.
MODE/SUBMERGED/TURBINE-REDUCTION/250FT/M/LLOYDS MIRROR// ;
MODE/SUBMERGED/-/250FT/M/LLOYDS MIRROR// ;
MODE/SUBMERGED/250FT/M/LLOYDS MIRROR// :
Example 2-9 – Correct and Incorrect Maintenance of Field Integrity

e. Occurrence Requirements. The use of the hyphen for Mandatory, Operationally

determined and Conditional occurrence categories is explained further in the Occurrence
Categories of Fields section below.
f. Unknown data items. In some cases, the data codes prescribed for a coded item
includes an individual entry data code representation for Unknown, e.g. UNK. When such a
data code is available, it must be used rather than the hyphen when the information to
complete the field is not known rather than not being available.
5. Occurrence Categories of Fields. Every field format position in a Set format is assigned an
occurrence category based on the necessity and structural relevance of the information within the set.
These occurrence categories remain constant regardless of the set usage in different Message formats.
As explained in para 0202.3, the occurrence categories are Mandatory, Operationally Determined and
Conditional. The following occurrence category rules apply to fields of a set.

a. Mandatory field position must be completed for every use of the set. Entry of a
hyphen "-" to represent a lack of data constitutes field completion.
b. Operationally Determined field position is to be completed when it is appropriate to
do so. Where data for any reason cannot be entered, the field may be omitted unless it is
followed by one which requires completion, in which case a hyphen "-" is entered.
c. Conditional field position has a condition governing its use in the set. That condition
must be explicitly stated in the set or Message Format specifications. If other fields following
such a field in a set are used, and the condition prohibits the use of the field, a hyphen "-" must
be entered.
6. Field Descriptors. A field descriptor is a word, abbreviation or acronym. It comprises of
one to eight alphabetic upper case or numeric characters followed by a colon ":" to separate it from the
data code that follows. The field descriptor is used if there is an operational requirement to cue the
user to the meaning of the field content or to identify the alternative used in an alternative content field.

2-16 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

CHAPTER 3 - MTF OPERATIONAL USER GUIDE

0301. Introduction

1. The message text formats (MTFs) which are linked Appendixes to Annex A as have been
agreed by NATO nations as meeting operational information exchange requirements. MTFs are in a
format that is man-readable and computer processable and are designed to be unambiguous and
concise. The information to be transmitted in a MTF message is sequentially ordered and the format
must be adhered to.

2. The User Format (UF) is a user oriented guide to aid the interpretation of a MTF.

0302. Aim

The aim of this Chapter is to provide guidance at the operational user level on how to read or write a
formatted message using the User Formats in Annex A.

0303. Assumption

It is assumed that the user does not have the assistance of message preparation software or sufficient
guidance with the messaging software. Where the user has software assistance they should be using
the software as a primary message preparation system. A more detailed interpretation of the rules
governing MTFs can be found in Chapter 2.

0304. Sections of the Message Text Format (MTF)

1. Making messages flexible enough to be able to pass information on a wide range of subjects
but also precise enough as to be able to be interpreted accurately and unambiguously by a computer
creates a requirement for a formal layout. The requirement for man readability makes the division of
the message into identifiable components advantageous.

2. The MESSAGE is the information part of a communication which could be over high grade
messaging, email, web service, fax or pen/paper. In fact MTFs are flexible and simple enough to be
passed over any bearer that can carry textual characters.

3. A SEGMENT is a number of SETs that are grouped together.

4. A SET is a collection of FIELDS about the same specific subject area. They start with a
keyword, such as MSGID and end with a double slash (//) e.g. Example 3-1.

MSGID/MISREP/APP-11(C)/ORIGINAL/SHAPE/-/20080704T123021Z/-/-
/NATO/NATO UNCLASSIFIED/RELEASABLE TO THE INTERNET//
Example 3-1 – MSGID Set

5. A FIELD is an individual text area. They are separated from each other by a single slash (/).

Note: A simple analogy would be to think as a Message as a letter, a Segment as a paragraph, a Set as
a sentence and a field as a word within the sentence.

0305. How to Read a Message

1. MTF messages will be received in one of 2 formats, these are either textual, Example 3-2 –
Textual MTF Example 3-2, or as an instance of a XML-MTF. Both of the formats contain the same

3-1 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

information; however, the textual version is more suited to man readability but can also be machine
read using appropriate software, while the XML-MTF is more suited to machine reading.

2. On receiving a MTF message the user will normally be presented with the man-readable
version as shown in Example 3-2, this may be on a screen or as a printout. This section is intended to
assist in interpreting the information contained in a message using the User Formats contained in
Annex A of this publication.

EXER/CMX 10/DISTAFF//
MSGID/AOD/APP-11(C)/ORIGINAL/SHAPE/001/JUL/-/-/NATO/NATO
UNCLASSIFIED//
REF/A/NUC1/SHAPE/DMY:02062003/AIR 051/NOTAL//
REF/B/TYPE:LTR/SACLANT/FEB2003/100/NOTAL/FN:4503B/FN:3780C//
Example 3-2 – Textual MTF

3. If the received message is similar to Example 3-3, the message is a XML-MTF and Chapter
4 should be referred to.

<?xml version="1.0"?>
<mtf:GeneralInformationMessage xmlns:mtf="urn:int:nato:mtf:app-
11(c):original:orbat" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation="urn:int:nato:mtf:app-
11(c):original:geninfomsg messages.xsd">
<ExerciseIdentification>
<ExerciseNickname>CMX 10</ExerciseNickname>
Example 3-3 - XML-MTF Instance

0306. Decoding a Message

1. Identify the Message. The first step in decoding a message is to identify which MTF the
message drafter used in order to create the message. To identify the correct MTF, locate the Message
Identifier Set which begins with “MSGID”. The MSGID will always be in the field following the Set
identifier “MSGID”. – This is “AOD” in Example 3-4.

MSGID/AOD/APP-11(C)/ORIGINAL/SHAPE/001/JUL/-/-/NATO
/NATO UNCLASSIFIED//
Example 3-4 – Identify the message using the MSGID set

2. The remainder of this set contains:

(1) /APP-11(C) - The publication the UF can be found in.

(2) /ORIGINAL - The change state of that publication.

(3) /SHAPE - The Originator of the message.

(4) /001 - The serial number of these messages sent in

the month.

(5) /JUL - The Month this message was sent.

(6) /-/- - 2 fields that were not required in this

message.

3-2 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

(7) /NATO - The Security Policy for the content of the

message.

(8) /NATO UNCLASSIFIED - Message Security Classification.

(9) // - End of Set marker.

3. Locate the User Format – The second step in decoding a message is to locate its User
Format in Annex A.

a. Annex A, Appendices 1 and 3 lists messages alphabetically by Message Title, MSGID

and by Functional Areas.
b. Annex A, Appendix 2 lists messages alphabetically by MSGID. (For more
information on the purpose of Appendix 2 see para 0104.7.b).
4. Verify the Version of the Message – As the sole repository for NATO MTFs, Annex A
may contain several versions of the same message depending upon operational requirements.

a. The version of the message is given in the MSGID Set in field position 2 and 3.
In Example 3-4, the MTF was published in the original release of APP-11(C). If the third
field position stated CH1, the MTF was published in the first Change to APP-11(C).
b. If the correct version is not found in Annex A, Appendix 1, search Appendix 2 and 3.
5. Check the UF. The next step in reading a message is identifying the purpose of the message
which is stated on the front page of the UF as shown in Figure 3-1. The UF contains information about
the MTF.

a. APP-11(C) – The publication release edition

b. F072 – The Message Reference Number
c. 1.0 – Version number used for configuration management
d. AOD (AIR OPERATIONS DIRECTIVE) – Message Identifier and long title
e. AJP 3.3 – Related Documents to the MTF
f. The purpose of the message and its use.
g. MC ASB - The sponsor of the MTF
h. Any notes which pertain to the MTF or amplification to the purpose or use of the
message.
i. In use – Status of the message.

3-3 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Figure 3-1 - Front Page of User Format

0307. Using the User Format to Decode a Message

1. Reading a Message Map – The Message Map provides a breakdown of the Message in
Segments and Sets. Compare the message in Example 3-2 and the Message Map in Figure 3-1. Each
Set in the message will correspond to a Set Identifier (SETID) in the Message Map.

2. Contents of a Message Map. A description of each column of the Message Map is given
in Figure 3-2. A decode for the meaning of the symbols in the first 2 rows of the message map are
shown in the footer of each page. The Seg, Alt, and Occ column contents are described in para 0202.
Note particularly the example of the Alternative set use symbols in the “Alt” column, this is explained
in para 0202.11.

3-4 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Seg This indicates whether or not a Set is contained in a Segment. Segments are
numbered using the “legal” numbering style. E.g. segment 2.1.1 is contained
within segment 2.1 which in turn is contained within segment 2.
Alt This indicates whether there is a choice of different SETs to use when creating
the message.
(The 1 indicates that this is the first time that an alternative is available in the
message. All the sets with the same number are included in the same alternative
group.
The # indicates that only 1 of the alternatives MAY be selected.)
Occ This indicates that the sets are Operationally Determined and the use is
determined by the message drafter.
SETID The first component you will see in each set (line on the message) in this case
EXER or OPER. Each SETID corresponds to a Set Map. See para 0203.2.
Seq Sequence Number – sequentially numbers all the SETs used in the message.
Set Format A full name for the SET.
Position name
Description Guidance on how to use the SET in the context of the message.
Figure 3-2 - Decode of first 2 rows of Message Map

3. Identifying Set Map. The Set Map lays out the components (fields) for each set, the UF
documentation for each message contains a Set Map for each set used in the message. The initial field
in each set provides the set name and is the indicator for the set map to be used to decode the meaning
of the fields. The third set used in Example 3-2 is the REF set, the set map for this set is shown
in Figure 3-3.

Figure 3-3 - Set Map

4. The table in the lower portion of Figure 3-3 shows the decode information for the first 3
fields if the set, an explanation of the column contents is shown in Figure 3-4,

3-5 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

No Lists the Field location in respect to the SETID. The first field to
follow the SETID is the “SERIAL LETTER”.
Designator Contains the name of the Field and any alternative formats which may
be used.
The first field following the SETID in the REF set is its “Serial
Letter”.
The second field can either contain the “MESSAGE TEXT FORMAT
IDENTIFIER” of a referenced message or a different
“COMMUNICATION TYPE”
Field Desc For clarity Field Descriptors may have been included in the message
design, the Field Descriptor is separated form the field content by a
colon “:”. Field Descriptors provide signposts to the field content. Eg
to clarify date format, DMY: may be have been include to indicate that
040565 is 4 May 65 and not 5 April 65.
Concept/Explanation/Examples The Concept/Explanation/Example contains additional text toand
examples where appropriate. It also contains the reference number of
the table to be consulted for the exact values to be used in the field.
Figure 3-4 - Decode of the REF Set

REF/A/NUC1/SHAPE/DMY:02062003/AIR 051/NOTAL//
REF/B/TYPE:LTR/SACLANT/FEB2003/100/NOTAL/FN:4503B/FN:3780C//
Example 3-5 – Instances of a REF set.

5. Reading a Set – The 2 instances of the Reference set (REF) that appear in the “AOD”
message are shown in Example 3-5.

6. Decoding Field content Using Field Tables. In MTFs, all fields have restrictions on their
content, characters and length. This may be a table of CODED ITEMS, or a RANGE of letters or
numbers as is dictated in the “Concept/Explanation/Examples”. Not all information can be so tightly
defined therefore there are INSTRUCTIVE entries which allow a free text entry but may have
restrictions such as only upper case letters.

a. A Coded List - The coded list provides standard abbreviations or a list of allowable
values. These prevent confusion because all users utilise the same abbreviation. This list is
short and relatively obvious. Example 3-6 shows a number of coded items such FEB in the
second line, the decode can be found in the appropriate table Figure 3-5. Using coded ensures
that the strong relationship of text transmitted and meaning are closely maintained.

3-6 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

REF/A/NUC1/SHAPE/DMY:02062003/AIR 051/NOTAL//
REF/B/TYPE:LTR/SACLANT/FEB2003/100/NOTAL/FN:4503B/FN:3780C//
Example 3-6 - REF Sets with coded items in bold.

Figure 3-5 - A typical list of coded items

b. Range Table. There are 3 types of ranges in MTFs. These are Integer ranges, Decimal
Ranges and Alpha-numeric Ranges.
(1) Integer Range: This table only allows a limited choice of entries in that field
which must be whole numbers; therefore the user cannot enter a time which makes a
day longer than 23 hours. An Integer Range table is shown in Figure 3-6

Figure 3-6 - An Integer Range

(2) Decimal Range: The second type of range is the decimal range. In this type
of range, decimal numbers can be entered. The explanation is normally completed to
provide additional guidance. An Decimal Range table is shown in Figure 3-7.

Figure 3-7 - Decimal Ranges

(3) Alpha-numeric Range: The third type of range is the Alpha-numeric Range.
In this range the first 2 and the final values given. The remaining values can be
calculated using these 3 pieces of information. Some characters may be omitted, these
characters can be found in the Omit column. An Alpha-numeric Range table is shown
in Figure 3-8

Figure 3-8 - Alpha-numeric Ranges

3-7 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

c. Instructive Field - The contents of these fields are only constrained by the types of
characters the user may employ. The length of the field is given by the bracketed numbers
after the table name. An Instructive Field table is shown in Figure 3-9, the minimum and
maximum length of the field in this case is 1-8.

Figure 3-9 - Instructive Fields

0308. Writing a Message Text Format (MTF)

1. The drafter is assumed to have a requirement to create a MTF using the APP-11 User Format
in Annex A, without the aid of any message preparation software. This means that any user that has
message preparation software should in the first instance use the associated documentation and help
facilities that are coupled with the software. If word processing software is used, it is recommended to
use a fixed-width font such as “Courier”; blank spaces are important to correct completion of MTFs,
specifically columnar set alignment.

2. It would be difficult for a user to write a MTF before knowing how to read a MTF. It is
recommended that users be familiar with section 0202 and 0305-0307.

3. Annex A contains a list of all messages broken down in Message Title, MSGID and
Functional Areas. If the user does not know the exact message that is required, it is recommended
that the functional area index is consulted.

0309. Using the User Format to Write a Message

1. After the relevant MTF message has been identified, the next step is to check the front page
of the associated User Format (see Figure 3-10). This has important information about the use of the
message, including the Purpose, and Related documents that may be useful in its completion.

2. Versioning is an important aspect of messaging. It is possible to have more then one version
of the message located in the Appendixes to Annex A. The most current version should be used unless
otherwise directed by the Operational Commander.

Figure 3-10 - Front Page of User Format

3-8 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

3. After the front page of the User Format, the rest of the document specifies the construction
of the message. The terminology used has specific meaning as detailed in Chapter 2. The main
components are:

a. SEGMENTs – A number of sets that are grouped together.

b. SETs – are a line (or lines) of text about the same specific subject area. They start
with a keyword (e.g. MSGID) and end with a double slash (//).
c. FIELDs – are the individual text areas (e.g. 001) and they are separated from each
other by a single slash (/).
4. The Message Map. The first part of the User Format is often called the Message
Map, Figure 3-11. It lays down the overarching rules for the construction of a message i.e., the order
in which the sets appear, and the rules associated with the construction of the message. The Message
Map also contains an important description of how each set is intended to be used.

Figure 3-11 - Message Map

5. The Message Map looks busy, but is simply made up of a table that shows all the possible
sets, options and rules that are required or optional used in the message. Each of the columns provides
specific additional information about how the set shall be used in the message. From left to right, the
column headings are:

a. Seg – Indicates if the sets are part of a segment. Shown above is a 3 set segment
indicated by the 1.1 in the segment column.
b. Alt – Indicates if another set can be used as an alternative (i.e., an option). Each
group of alternatives are identified by having the same number in this field. There are 3

3-9 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

different ways that alternatives may be employed. Sets that can be used as alternatives are
identified by a number and possibly with a modifying symbol when appropriate:
(1) Number - Only 1 of the alternatives (with the same number) MUST be
selected.

(2) # - Only 1 of the alternatives MAY be selected

(3) * - One or more alternatives MUST be selected.

c. Rpt – A tick 9 in this field indicates that a set may be repeated. Example above
shows that REF may be repeated an unlimited number of times. If a number appears after the
e.g. 95 then set may only be repeated up to 5 times.
d. Occ – Shows the occurrence of the set.
(1) M = Mandatory, The set must be included in the message.

(2) C = Conditional, There are rules relating to the inclusion of the set in the
message, the rules for the set immediately follow the set.

(3) O = Operationally Determined, The set may be included in the message if

the author has information to pass.

e. SETID – Indicates the name of the Set, and for those users with an electronic copy of
the User Format, a hyperlink to the Set map. The name of the set – SETID - is used to start
each set in the MTF followed by a "/" (slash) character.
f. Set Format Position Name – indicates the full name of the set (not used when
writing a MTF), which makes it easier for the user to identify the Set usage.
g. Description – Provides additional information about how the function of the set
within the message.
6. Free Text Sets. There are a number of free text sets used in MTFs. In the message map
only the GENTEXT set is shown. This set always has the set identifier GENTEXT followed by the
content identifier that is assigned in the rule following each GENTEXT set in the message map; e.g.
“FIELD 1 IN SET 14 (GENTEXT) IS ASSIGNED THE VALUE /MISSION/.”. The assigned
identifier must be copied exactly as shown in the message map including spelling and spaces.

GENTEXT/MISSION/The mission focuses on the training of the NATO

Response Force (NRF) by using a scenario centered on a fictitious
group of islands in the North Atlantic off the coast of Africa.//
Example 3-7 - Free Text Set

7. The message drafter can add additional free text, notwithstanding the message map, which
can appear at any point in a message and can be one of the following set types:

a. AMPN – Amplification. If the free text only relates to the preceding set then the
AMPN set must be used.
b. NARR – Narrative. If the free text relates to more than one adjacent sets then the
NARR set is used after the last set that the NARR refers too.
c. RMKS - Remarks. If the free text relates to the whole message than a RMKS set is
used at the end of the message. Only 1 RMKS set can be used in a message.

3-10 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Note. It is prohibited to have 2 consecutive occurrences of AMPN and NARR.

8. These 3 types of set have the set identifier AMPN. NARR or RMKS which is followed by a
“/” characters and then the text. At the end of the free text a double slash, “//”, must be used to indicate
that that is the end of the set. Example 3-8 shown how an AMPN set would appear in a message. See
para 0203.17 for more details on the use of Freetext field.

AMPN/Amplification text goes here//

Example 3-8 - AMPN Set

9. Set Content. Sets are constructed in a similar manner using the relevant set map, as
specified in the user format. See Figure 3-12. Set maps identify the sequence that fields appear in the
set.

Figure 3-12 - Set Map for the MSGID Set

10. The Set Map includes information for the message drafter, in a similar manner to the
message map; the Set Map shows the fields which make up a Set. Field occurrence uses the same
code (M, O, C) as used in the Message Map level. The minimum and maximum number of characters
that can be included in each of the fields is also shown.

11. Each set starts with the set identifier which is followed by a "/" character. Spaces must not
be inserted either before or after the "/" character (except in the case of columnar sets where spaces are
used for alignment, see para 0203.16.d). All mandatory fields must be included in the set, if there is
no data available for inclusion in a mandatory field, the field should be filled with a hyphen "-"
character. The operationally determined fields are completed as required by the message drafter.

3-11 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Finally the Set is terminated with a "//". If no further operationally determined fields are required, the
set may be terminated prematurely with "//" characters.

12. Columnar Set Construction - Columnar sets are formatted so that data codes appear in
tabular form under appropriate column headers.

a. The first line of a set for columnar presentation contains only the set format identifier.
The identifier begins with one numeric character.
b. The second line contains the column headings. Each column begins with a field
marker (/) and contains the exact title and spacing specified in the user instructions.
c. Data is reported in the third and subsequent lines. Each entry in each column begins
with a field marker (/). Alphabetic and alphanumeric data are left justified in a column.
Numeric data are right justified. The data reported must be spaced exactly as shown in the user
instructions. If an item of information is not known when completing a line of data, a hyphen
(-) must be entered in the appropriate column. This hyphen will be justified the same as other
entries in that column.
d. he set ends with an end-of-set marker(//) which is positioned immediately after the last
data code of the last field. However, it will be placed on However, it will be placed on the
next line if the final data code extends beyond the 67th character position.
13. Line Breaks within a set – When a set contains more than the number of characters that the
method of transmission allows, eg ACP-127 has a maximum line length of 69 characters, the set it
must be continued onto a line or subsequent lines, without repetition of the set format identifier, as
follows:

a. field must not be split between lines; therefore, continuation lines must always begin
with the field marker (/) of the following field. See Example 3-9.
AREA/AREA 1/5500.12N-02000.34W/5500.12N-01000.34W/5400.12N-01000.34W
/5400.12N-02000.34W//
Example 3-9 – Liner Set showing correct form for a line break

b. A free text field that can be continued on one or more subsequent line(s). see Example
3-10
AMPN/USS GEORGE WASHINGTON WILL BE OPERATING IN THIS AREA DURING
NIGHT OF 15/16 JUNE//
Example 3-10 – Freetext set showing correct form for a line break

c. The end-of-set marker must not be split between lines. Thus, a continuation line may
occasionally contain only the end-of-set marker. See Example 3-11.
COMMS/CTF40/ABC/333.3MHZ/P/VOICE/222.2MHZ/S/VOICE/S/303.0MHZ/T/VOICE
//
Example 3-11 – Freetext set showing end of set marker in next line break

14. The message drafter must take care to ensure that the correct position (i.e., sequential order)
of operationally determined fields is maintained by using the "-" characters for empty operationally
determined fields in the set. At the end of a Set, one or more of the fields may be repeated; repeatable
fields can be identified by the word "REPEATABLE" under the fields of the set map, Figure 3-13.

3-12 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Figure 3-13 – Repeatable Field

15. Field Content. The content of each field is determined by the related table that is identified
in the "Concept/Explanation/Examples" notes for the field, under the "Field Filler Notes", that follows
the set map, Figure 3-14.

Figure 3-14 - Field Content Explanation

16. For each field the explanation provides a context to use that field and the number of the
relevant table. The tables that are referred to are either a data code list, an instructive entry or a range.

a. Data Codes. Where the table is a coded list, the message drafter will need to refer to
the correct table to identify the allowable content of the field. The only information that will
be allowed in the field will be taken exactly as written in the Data Code column of the table. A
typical codes list table such as in Table 1004/001 – Month Names is shown in Figure 3-15.

Figure 3-15 – Data Code List Table

b. Instructive Entries. These types of tables give instructions on the type of data that is
to be entered into the field. The explanation in the set map must be studied to determine the
information required. The relevant table must also be referred to determine the minimum and
maximum length of the field and also to identify which characters are permitted. These
limitations should not be discarded and are important if the message is to be successfully read
by a machine on receipt. A typical instructive entry table is shown in Figure 3-16, note the
minimum and maximum length (1-8) and the list of legal characters that can be used, for an
explanation of Special and Extended Special Characters see para 0204.3.c(3).

Figure 3-16 - Example of Instructive Entries

c. Ranges: Where a range is given, the entry in the field must lie within the range. If the
range is a simple range such as Reference letter [A, B through Z], this information will be
included in the set map so that reference to the appropriate table is not necessary, however, if

3-13 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

the range is more complex it will be necessary to refer to the appropriate table. There are 3
types of ranges, and Integer Range, a decimal Range and an Alpha-numeric Range.
(1) Integer Range - An integer range is specified using the minimum inclusive
integer value and the maximum inclusive integer value of the range with intermediate
values understood to be whole numbers. Allowed characters for integer range are the
characters "0" through "9". If permitted, the "-" may be used to show a negative value.
An integer range is specified as either fixed or variable length. Where it is a fixed
length, a leading "0" characters must be inserted. Figure 3-17 shows an integer range
with a fixed length.

Figure 3-17 - Integer Range Table

(2) Decimal Range. A decimal range is specified using the minimum inclusive
value and the maximum inclusive value of the decimal range. A decimal range
specifies either a fixed number or a range of decimal places (digits to the right of the
decimal point). A fixed number decimal place specification indicates that all values
contain the same number of decimal places (specification of zero decimal places is not
permitted). A range of decimal places specifies the minimum and maximum value
over which the number of decimal places may vary (range values are zero or greater).
Values without decimal point are only allowed when the minimum range of decimal
places is zero. Allowed characters for decimal range are the same as for integer range
and the decimal point character ".". A decimal range is specified as either fixed or
variable length. A typical decimal range table is shown in Figure 3-18.

Note: In some decimal range tables the format for decimal numbers less than 1 may be required be
written without an integer part i.e. “.5” for a value of “0.5”.

Figure 3-18 - A Decimal Range

(3) Alpha-numeric Range. This type of range, can be made up of alphabetic or

a mix of alphabetic and numeric characters. In most cases the first couple of values
and the last value are given, the message drafter is expected to interpolate other
allowable values. A list of values that are to be omitted may also be given. In a small
number of cases where the range is very complex it may be represented by a form of
computer code known as a regular expression. In this case an explanation will be
given for clarity. A typical alpha-numeric range table is shown in Figure 3-19

3-14 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Figure 3-19 – An Alpha-numeric Range

17. Alternative Formats. For some fields, alternative formats for the information may be
available to the message drafter, such as in the date formats (DDMMYYYY, MMDDYYYY or
YYYYMMDD). In these cases the message drafter should select the most appropriate format using
the relevant table for the selected field. In some cases a field descriptor must be used. These are
shown in the "Field Desc" column of the "Field Filler Notes" and are only associated with a single
alternative. The field descriptor is used by message readers to identify which alternative has been used
when the data in the field could be ambiguous. Field descriptor prefixes the data in the field and is
separated from the field content by a colon":", neither of which are included in size count for the
field. Figure 3-20 shows part of a set map for a field with several alternatives. Note that field
descriptors are required for alternatives E and F. Example 3-12 shows how a field descriptor is used in
a message.

Figure 3-20 – Field with Alternatives and Field Descriptors

REF/A/TYPE:DOC/CAOC 9/DMY:01062008/RAF-123/097723//
Example 3-12 - Set showing field descriptor in field 2 and 4

18. Composite Field - A Composite Field Format is a sequence where 2 or more elements are
specified. Concatenating elements together in a single field is considered during the design of a
message to make the reading of the field easier for humans while still maintaining the required
separation of individual pieces of data for machine readers (see para 0204.2.b for more details). There
is no option to insert a hyphen to replace an elemental value within a composite field, either all the
data must be inserted or a single hyphen used for the whole field (see para 0204.4.a(2)). Figure 3-21
shows Date of Reference DDMMYYY, example of the composite table.

Figure 3-21 - Composite Table

19. The data codes that are associated with the allowable data in the table produce the result
from the concatenation of the data items and data codes of the elemental fields that make up the
composite.

3-15 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

0310. Completing the Message.

Having completed the set the message drafter should refer to the Message Map to locate the next set to
be included in the message repeating this process until the message is completed.

3-16 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

CHAPTER 4 - XML-MTF
0401. Purpose

1. The purpose of this chapter is to provide operators with information which allows them to
recognise a MTF message received in Extensible Markup Language (XML) format.

2. This chapter does not provide an education in XML. Detailed XML information can be
found in many commercial publications or self teaching aids on the Internet.

0402. Introduction to XML

1. XML is used to ‘tag’ information which allows a computer to process it and a user to read it.
In other words, a general-purpose specification to allow organisations to define their own data
elements. XML-MTF is one such specification. Its primary advantage is to facilitate the sharing of
structured data across different computer systems, via any network, for example NSWAN or the
Internet.

2. A XML version of formatted messages has been produced by NATO. The operational
content of the message formats (traditional textual MTF and XML-MTF) is identical. Textual format
is useful for message delivery where bandwidth of the network is limited; XML format is better suited
to computer-to-computer data ‘understanding’. Conversion from one format to the other can be
achieved through software.

3. There are 3 fundamental parts associated with XML a XML schema that defines the rules for
a XML Instance, a XML Instance is the actual data to be transmitted, (ie a XML-MTF) and a Style
Sheet which provides a layout for the way a XML Instance will be viewed. The XML schema and
XML Instance are essential information; the Style Sheet is optional. Further definition of the
terminology is given below:

a. XML Schema. The XML rules for each XML-MTF message are called a schema
which contains all the tag names for the fields and any limitations on field content. Well
designed XML documents allow information systems to exchange structured data in an
unambiguous manner. By using the schema as a framework a computer can map data from an
instance of a message to applications such as spreadsheets, databases and situational
awareness programs.
b. XML Instance. This is an instance of a message that conforms to the rules for that
message in the associated schema. Each element of data in a XML Instance is held between
opening and closing tags (words bracketed by '<' and '>') which have unique names that
describe the data, Example 4-1 shows a tagged element. Note that the closing tag is identical
to the opening one but starts with “</”. It is possible to read data received in a XML Instance
manually, but the size of the document can make this a difficult task. Fortunately when a XML
document is combined with an XSL Style Sheet, in a computer generated view eg a browser,
the data can be easier to read.
<ExerciseNickname>OPEN GATE 09</ExerciseNickname>
Example 4-1 - A tagged element

c. XSL Stylesheet. (EXtensible Stylesheet Language) describes how the XML Instance
should be displayed. Numerous style sheets can be created for viewing the same type of XML
Instance, each showing different sets of message data or laying the same message data out in
different ways.

4-1 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

Note: When viewing a message with a style sheet, operational users should always be aware that they
may not be able to see all the information that was contained in the message.

0403. Examples

1. To show a comparison between the same message in the 2 formats (textual and XML-
MTF), Example 4-2 and Example 4-3 show how the same data payload would appear.

a. The traditional textual format is shown in Example 4-2, The message is laid out as
described in Chapter 3, with “/” characters delimiting the data and the meaning of the data
determined by the position that the field occurs.
EXER/OPEN GATE 09//
MSGID/GENINFO/APP-11(C)/ORIGINAL/SHAPE/-/20090628T123500Z/-/-
/NATO/NATO UNCLASSIFIED//
REF/A/TYPE:DOC/SHAPE/20APR2009//
GEODATUM/WGE//
SUBJECT/MAIN PLANNING CONFERENCE//
GENTEXT/GENERAL INFORMATION/THE MAIN PLANNING CONFERENCE FOR OPEN
GATE 09 WILL BE HELD.....//
Example 4-2 – Textual version of a GENINFO message

b. The same information in XML-MTF format would appear in the format shown
in Example 4-3. Every field is tagged which allows a computer to locate data in the message.

4-2 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

<?xml version="1.0"?>
<mtf:GeneralInformationMessage xmlns:mtf="urn:int:nato:mtf:app-
11(c):original:geninfomsg" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation="urn:int:nato:mtf:app-11(c):original:geninfomsg
messages.xsd">
<ExerciseIdentification>
<ExerciseNickname>OPEN GATE 09</ExerciseNickname>
</ExerciseIdentification>
<MessageIdentifier>
<MessageTextFormatIdentifier>GENINFOMSG</MessageTextFormatIdentifier>
<Standard>APP-11(C)</Standard>
<Version>ORIGINAL</Version>
<Originator>SHAPE</Originator>
<ReferenceTimeOfPublication>
<DateTimeIso>
<Year4Digit>2009</Year4Digit>
<MonthNumeric>06</MonthNumeric>
<Day>28</Day>
<TimeDelimiter>T</TimeDelimiter>
<HourTime>12</HourTime>
<MinuteTime>35</MinuteTime>
<SecondTime>00</SecondTime>
<TimeZoneZulu>Z</TimeZoneZulu>
</DateTimeIso>
</ReferenceTimeOfPublication>
<MessageSecurityPolicy>NATO</MessageSecurityPolicy>
<MessageSecurityClassification>
<MessageSecurityClassificationExtended>NATO
UNCLASSIFIED</MessageSecurityClassificationExtended>
</MessageSecurityClassification>
</MessageIdentifier>
<Reference>
<SerialLetter>A</SerialLetter>
<CommunicationType>
<CommunicationType>DOC</CommunicationType>
</CommunicationType>
<Originator>SHAPE</Originator>
<DateAndOrTimeOfReference>
<DateOfReferenceDdmmmyyyy>
<Day>20</Day>
<MonthNameAbbreviated>APR</MonthNameAbbreviated>
<Year>2009</Year>
</DateOfReferenceDdmmmyyyy>
</DateAndOrTimeOfReference>
</Reference>
<GeodeticDatum>
<GeodeticDatum>WGE</GeodeticDatum>
</GeodeticDatum>
<MessageSubject>
<TextIndicator>MAIN PLANNING CONFERENCE</TextIndicator>
</MessageSubject>
<GeneralInformation>
<TextIndicator>GENERAL INFORMATION</TextIndicator>
<FreeText>THE MAIN PLANNING CONFERENCE FOR OPEN GATE 09 WILL BE
HELD.....</FreeText>
</GeneralInformation>
</mtf:GeneralInformationMessage>
Example 4-3 - A XML view of a GENINFO message

2. The data in Example 4-3 can be difficult to pick out; however, when combined with a style
sheet and web browser, relevant content can be displayed, normally in html. Figure 4-1, is an example
of how the message in Example 4-3 can be presented with a style sheet. It should be noted that the text

4-3 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

in the message should not be altered; however, the surrounding text could be translated into the local
language.

Figure 4-1 - Example 4-3 combined with a style sheet

0404. XML-MTF or MTF?

When determining the format to be used for sending a MTF, the message originator should consider
the needs of the recipient, their ability to convert from one format to the other and the bandwidth
available. It may be necessary for message originators to produce both formats of the same message.
The format to be used on systems should be detailed in operational orders.

0405. Provision of XML-MTF Schemas

1. The authoritative source for XML schemas for messages is the NATO XML Metadata
Registry. The schemas are distributed using a number of methods:

a. APP-11. Annex A of this document contains a set of XML schemas for each message.
b. NATO XML registry. This is held as part of the United States Department of
Defence (DOD) Metadata Registry (http://metadata.dod.mil). The web-based DOD metadata
repository is designed to act as a clearinghouse and coordination centre for industry and
government metadata technology and related issues. Access to the DOD Metadata Registry
requires a .gov or .mil or nato.int address or sponsorship by a .gov or .mil address.
2. The schemas provided for MTFs contain a single message. Combining more than one message
into a schema is not considered practical due the size of the resulting files.

3. NATO style sheets, if available, will be published in Annex A.

0406. Best Practice for Systems Implementation

1. The following guidance is provided for procurement and implementation of systems that use
XML-MTFs.

a. Message Automation – The latest version of all messages (Appendix 1 to Annex A

(A-1)) should be automated in their entirety. However, for a specific system it may not be
practical to automate the entire message catalogue or all parts of a message. Where a message
is partially automated this partial implementation should be carefully documented so that end

4-4 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

users are aware of any limitations. However, end users must be given the capability to view all
data that is received in any MTF message irrespective of the level of automation that can be
applied to it.
b. Validation of XML-MTF Instances – When validating an instance of a XML-MTF
message against a schema, the rules associated with the message must also be taken into
account as well as the data content; standard XML software will generally not check this.
c. Changes to message – Messages in this catalogue will be subject to modification over
time to meet changing operational needs. Consideration should be given to system design to
ensure that sufficient flexibility is built in to be able accommodate these modifications within
a reasonable timescale whilst retaining the ability to at least interoperate with at least one
previous version (Annex A, Appendix 3) of the message.
d. Metacard Specification – Where instances of messages are stored on a system and
there is a need for the messages to be searchable, the FORMETS Discovery Metadata
Specification (FDMS) should be used to advertise the instance of the message.

4-5 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

CHAPTER 5 - VOICE TEMPLATES

0501. Purpose

1. Voice Templates provide a voice format for use when data communications are not available.

2. They assist in ensuring the integrity of the information content of a MTF, when it is
transferred to a voice communication system, or vice versa.

0502. Scope

1. It is essential that the VTs in APP-11 are coherent with their associated MTF.

2. VTs cannot be used for information exchange over automated CIS.

0503. Responsibility

The message sponsor of a MTF is responsible for the development and configuration management of
the associated VT if one is required. Where voice templates are required, the sponsor should ensure
that the publication of new or modified MTFs and associated VTs, irrespective of the operational
urgency, is conducted in a coherent manner.

0504. Structure

1. The structure of a VT is to include the following elements:

a. Message Title - To contain the long and short MTF message titles.
b. Message Purpose Statement - To include the MTF purpose statement and a message
usage summary.
c. Message Reference - To specify the NATO message sponsor and the associated MTF
Message Reference Number.
d. Information Content Table - To contain the information contained in the associated
MTF in the same sequence and in the same level of detail, where possible.
e. Notes - To expand the meaning of the information elements in the information content
table.
2. The structure of a VT is shown Figure 5-1.

5-1 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

0505. Presentation

Figure 5-1 – Voice Template Format

1. The main emphasis within the presentation of a VT is the need for brevity, clarity and
consistency.

2. Although the presentation of the information content within a VT is based on the structure
and information content of its associated MTF, it is not always possible to reflect this exactly, for
example, owing to segmentation within the associated MTF. Any deviation between the information
content within the VT, and the information content within the associated message text format, must be
authorized by the MTF sponsor.

3. Wherever possible, a VT should be contained within a single page. This is not always
achievable with some VTs, owning to the length and complexity of their associated MTFs.

4. The right-hand column of the information content table indicates the maximum number of
characters that can be used to complete each information element. This information is for guidance
only, and in order to encourage brevity. It is not a mandatory requirement.

0506. Development

Once the NATO ADatP-3 message sponsor has produced the associated VT and has operationally
validated the VT, it is to be approved through the normal operational process.

0507. Configuration Management

1. The NATO ADatP-3 message sponsor is responsible for VT configuration management.

2. A change to an existing VT is only permissible when:

a. It results from an authorized change to the associated UF.

b. The existing VT is not consistent with the existing associated UF.
3. The staffing process for the submission of a change proposal to a VT is the same as for the
development of a VT.

5-2 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC/PfP UNCLASSIFIED
APP-11(C)

0508. List of Voice Templates

A list of Voice Templates is located in Annex B.

5-3 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC UNCLASSIFIED
APP-11(C)

CHAPTER 6 - STRUCTURED MESSAGES

0601. Purpose

1. This chapter contains the drafting instructions for the few remaining structured messages in
the obsolescent Maritime Tactical Message System (MTMS). Messages in this format will be replaced
by MTFs in the imminent future.

2. Although structured messages appear to have a formal construction, the rules for their
creation are very liberal which means that they are unlikely to be capable of successful automation.
Structured Messages are structured in such a way that the contents of the component sections appear in
free text, or in established sequences which are repeatable and may be amplified.

0602. Drafting Instructions for Structured Messages

1. Message sections are distinguished using an alpha-numeric identifier which is followed by a

slant, a self-explanatory abbreviation, a further slant and then the text. Each section, with its
associated identifier, abbreviation and text is to be started on a new line. Unlike MTFs there is no
marker at the end of each section. A typical section of a message is shown in Example 6-1.

B4/AAWPICK/BRISTOL/R6F/TOMCAT/345ZZ67
Example 6-1 - Typical structured message section

2. Readability may be improved by indenting the second and subsequent lines after the self-
explanatory abbreviation.

3. Free Text sections may be specified in the structure, these appear in the same manner as any
other section with an alpha numeric identifier and a section abbreviation. See Example 6-2.

C13/AEWMISSN/E2 WILL REPORT SURFACE CONTACTS IN A

SECTOR AHEAD 123 NM 45 DEG EACH SIDE OF PIM. PRIMARY
TARGET IS OPFOR SAG. E2A REPORT SURFACE CONTACTS IN
VIC OF AOA.
Example 6-2 - Free text section

4. Establish Sequences. The sequence for sections and blocks are shown in the structure for
each message in Annex C. The sequence of information in the message should be adhered to otherwise
the risk of miss interpretation increases:

a. Within a section, blocks of data are separated by slants. Within a block of information,
required items are separated by periods, spaces, hyphens, etc., but not by a slant. In addition,
slants are not to be used for abbreviations such as N/A, A/C, etc. These must be written NA,
AC, etc, or the words spelled out. To ensure that the required sequence of specified
information is maintained, hyphens are to be entered where there is no information except as
exempted in the detailed instructions, or if it is clear that the correct sequence will not be lost.
A section using slant delimiters is shown in Example 6-3.
B4/AAWPICK/BRISTOL/R6F/TOMCAT/345ZZ67
Example 6-3 - Slant delineation

5. Amplifying data. Elements may be amplified by inserting the appropriate text at the end of
the block, separated by a dash. In amplifying an entire sequence, appropriate text may be inserted at

6-1 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC UNCLASSIFIED
APP-11(C)

the end, separated from the last element by a slant. An example of a section with amplifying text is
shown in Example 6-4.

E4/SAFESECT/GOLF/VICTOR LIMA/100NM NORMALLY-FROM 182000Z1 TO

182200Z3 150NW/235/10/FL100/DISESTABLISHED 220001Z5.
Example 6-4 - Section with amplifying text added to the third block

6. Repeating Sequence. The repetition of sections or blocks is permissible, although message

originators have to make it obvious that this has occurred. Repetition can be achieved using one of the
following methods:

a. Continuous repetition of a series of blocks is permissible; however, in the interest of

readability, this is only to be used for short sequences requiring little repetition. An example of
this repetition format is shown in Example 6-5.
B3/SURFAAW/KIDD/GOLF/000ZZ30/ROGERS/GOLF ALFA/120ZZ10
/BROADSWORD/GOLF BRAVO/240ZZ10
Example 6-5 – Continuous repetition of blocks

b. Repeating the sequence of block on a new line without an alpha-numeric identifier,

and self-explanatory abbreviation. This method is appropriate for shorter sequences requiring
a lot of repetition. An example of this repetition format is shown in Example 6-6.
B3/SURFAAW/KIDD/GOLF/000ZZ30
/ROGERS/GOLF ALFA/060ZZ10
/BROADSWORD/GOLF BRAVO/120ZZ10
/ILLUSTRIOUS/ECHO/ZZ
/MACDONOUGH/HOTEL/180ZZ5
/SPRUANCE/HOTEL ALFA/240ZZ10
/ALGONQUIN/HOTEL BRAVO/300ZZ10
Example 6-6 – Repetition using line separation

c. Repeating the whole section, including the alpha-numeric identifier and self-
explanatory abbreviations on a different line for each sequence. This is appropriate for
lengthy sequences. An example of this repetition format is shown in Example 6-7.
G1/EMCON/ALFA/A-14E-1A-40P-51P-66U-81UV-82A-90EB-B-14F-40P-51P-8U-
82H-90EB-L-10U-40P-60U-80M-84U
G1/EMCON/BRAVO/A-10U-30U-60U-80U-B-10U-20U-40P-60U-80U-L-10E-20E-
40P-85U
Example 6-7 - Repetition using sections

7. Amplifying Repeated Sequences. All repeated sequences in the same section can be
amplified by adding the same alpha-numeric identifier and self-explanatory abbreviation, followed by
amplifying text at the end of the section. An example of this form of amplification format is shown
in Example 6-8.

6-2 Original
NATO/EAPC/PfP UNCLASSIFIED
 NATO/EAPC UNCLASSIFIED
APP-11(C)

B3/SURFAAW/KIDD/GOLF/000ZZ30
/ROGERS/GOLF ALFA/060ZZ10
/BROADSWORD/GOLF BRAVO/120ZZ10
/ILLUSTRIOUS/ECHO/ZZ
/MACDONOUGH/HOTEL/180ZZ5
/SPRUANCE/HOTEL ALFA/240ZZ10
/ALGONQUIN/HOTEL BRAVO/300ZZ10
B3/SURFAAW/ON DETECTION OF NUCLEAR THREAT STATION RANGES ARE TO BE
INCREASED BY 20 NM WITHOUT FURTHER ORDERS.
Example 6-8 - Amplification of repeated blocks or sections

8. Avoid Lengthy Messages. To conserve bandwidth, sections which are not required should
be omitted.

9. Change Instructions. Previously promulgated messages can be modified in the course of

an operation as follows:

a. Changes to promulgated messages. This method has the advantage of allowing some
degree of separation between perishable and non-perishable information, thus reducing
repetition of the same text in subsequent messages. It is described below:
(1) Changes are identified by MSGID followed by the title of the message being
changed, followed by "CHANGE", followed by a three-figure number indicating the
change serial, followed by the effective date time group (DTG) of the change, with
each separated by a slant. The complete message identifier is not given because, as
explained in section A1 of each message structure, referencing the message to be
changed is mandatory. An example of the initial section of a change message is shown
in Example 6-9.

A1/MSGID/OPTASK AAW/CHANGE/003/021200Z5
Example 6-9 – Message ID with a change

(2) To delete a section in an existing message, the appropriate section alpha-

numeric identifier is listed, followed by "DELETE". An example of a deleted section
is shown in Example 6-10.

E3/DELETE
Example 6-10 – A deleted section

(3) To add a new section to an existing message, its complete text, including the
alpha-numeric identifier and self-explanatory abbreviations, is inserted.

(4) For major amendments to a section in an existing message, the complete

section, including the alpha-numeric identifier, self-explanatory abbreviation, and
revised text, are inserted. For minor amendments the alpha-numeric identifier, self-
explanatory abbreviations and directions for the amendment only are necessary.

(5) The order of the contents of a change message is to conform to the structure
sequence of the message to be changed.

b. Promulgation of the replacement message. A replacement message is promulgated

using the next sequential serial number and will automatically supersede its predecessor.

6-3 Original
NATO/EAPC/PfP UNCLASSIFIED