Acp 123

UNCLASSIFIED ACP 123(A)
COMMON MESSAGING
STRATEGY
AND PROCEDURES
ACP 123
Edition A
15 August 1997
UNCLASSIFIED I ORIGINAL
(Reverse Blank)
UNCLASSIFIED ACP 123
Foreword
1. ACP 123, COMMON MESSAGING STRATEGY AND PROCEDURES, is an UNCLASSIFIED

publication. Periodic accounting is not required.
2. ACP 123 will be effective for National, Service, or Allied use when directed by the appropriate
Implementing Agency, refer to the National Letter of Promulgation (LOP).
3. This publication contains Allied military information and is furnished for official purposes only.
4. This publication is not releasable without prior approval from the United States Military
Communications-Electronic Board (USMCEB).
5. It is permitted to copy or make extracts from this publication without consent of the Authorizing
Agency.
UNCLASSIFIED III ORIGINAL

(Reverse Blank)
LETTER OF PROMULGATION
UNCLASSIFIED V ORIGINAL
(Reverse Blank)
RECORD OF CHANGES AND CORRECTIONS
Enter Change or Correction in Appropriate Column
Identification of Change or Correction; Reg. No. (if Date Entered By whom entered
any) and date of same (Signature; rank, grade,
or rate; name of
command)
Change Correction
UNCLASSIFIED VII ORIGINAL

RECORD OF CHANGES AND CORRECTIONS
Enter Change or Correction in Appropriate Column
Identification of Change or Correction; Reg. No. (if Date Entered By whom entered
any) and date of same (Signature; rank, grade,
or rate; name of
command)
Change Correction
UNCLASSIFIED VIII ORIGINAL

RECORD OF PAGES CHECKED*
Date Checked By Whom Checked (Signature and Date Checked By Whom Checked (Signature and
Rank) Rank)
*THIS PAGE NOT APPLICABLE TO US HOLDERS
NOTE: To meet local requirements, this page may be replaced when all entries are filled. The
publication holder is to arrange local reproduction, and certify the replacement pages as a true
copy. The original page numbers are to be allocated to the copy. Superseded pages should then
be destroyed in accordance with applicable National instructions.
UNCLASSIFIED IX ORIGINAL
RECORD OF PAGES CHECKED*
Date Checked By Whom Checked (Signature and Date Checked By Whom Checked (Signature and
Rank) Rank)
*THIS PAGE NOT APPLICABLE TO US HOLDERS
NOTE: To meet local requirements, this page may be replaced when all entries are filled. The
publication holder is to arrange local reproduction, and certify the replacement pages as a true
copy. The original page numbers are to be allocated to the copy. Superseded pages should then
be destroyed in accordance with applicable National instructions.
UNCLASSIFIED X ORIGINAL
Table of Contents
Foreword ......................................................................................................................................III
Letter of Promulgation .................................................................................................................. V
Records of Changes and Corrections.......................................................................................... VII
Table of Contents .........................................................................................................................XI
List of Figures............................................................................................................................ XVI
CHAPTER 1
GENERAL
SECTION I
INTRODUCTION
101. Background.........................................................................................................................1-1
102. Evolution ............................................................................................................................1-2
103. Scope .................................................................................................................................1-2
104. Overview ............................................................................................................................1-3
105. Structure of the Document ..................................................................................................1-7
SECTION II
DEFINITION OF TERMS USED IN THIS PUBLICATION
106. Definitions...........................................................................................................................1-7
107. Abbreviations.................................................................................................................... 1-11
CHAPTER 2
MESSAGE SERVICES – ELEMENTS OF SERVICE
SECTION I
MM ELEMENTS OF SERVICE ADOPTED FROM IPMS
201. Basic X.400 Elements of Service ........................................................................................2-1
a. Access Management .......................................................................................................2-2
b. Content type indication ................................................................................................2-2
c. Converted indication....................................................................................................2-2
d. Delivery time stamp indication.....................................................................................2-2
e. MM identification .........................................................................................................2-2
f. Message identification .................................................................................................2-2
g. Non-delivery notification ..............................................................................................2-3
h. Original encoded information types..............................................................................2-3
i. Submission time stamp indication................................................................................2-3
j. Typed body..................................................................................................................2-3
k. User/UA Capabilities Registration ................................................................................2-3
202. Optional Elements of Service..............................................................................................2-4
a. Alternate recipient allowed...........................................................................................2-4
b. Alternate recipient assignment.....................................................................................2-4
c. Authorizing users indication .........................................................................................2-4
d. Auto-forwarded indication ............................................................................................2-4
e. Blind copy recipient indication......................................................................................2-4
f. Body part encryption indication ....................................................................................2-5
g. Conversion prohibition .................................................................................................2-5
h. Conversion prohibition in case of loss of information ...................................................2-5
i. Cross-referencing indication ........................................................................................2-5
j. Deferred delivery .........................................................................................................2-6
k. Deferred delivery cancellation .....................................................................................2-6
l. Delivery notification .....................................................................................................2-6
m. Designation of recipient by directory name ..................................................................2-6
n. Disclosure of other recipients.......................................................................................2-7
UNCLASSIFIED XI ORIGINAL
202. (continued)
o. DL expansion history indication ...................................................................................2-7
p. DL expansion prohibited ..............................................................................................2-7
q. Expiry date indication ..................................................................................................2-7
r. Explicit conversion.......................................................................................................2-7
s. Forwarded MM indication.............................................................................................2-7
t. Grade of delivery selection ..........................................................................................2-8
u. Hold for delivery ..........................................................................................................2-8
v. Incomplete copy indication ..........................................................................................2-8
w. Language indication.....................................................................................................2-9
x. Latest delivery designation ..........................................................................................2-9
y. Multi-destination delivery .............................................................................................2-9
z. Multi-part body.............................................................................................................2-9
aa. Non-receipt notification request indication.................................................................. 2-10
ab. Obsoleting indication ................................................................................................. 2-11
ac. Originator indication................................................................................................... 2-11
ad. Originator requested alternate recipient ..................................................................... 2-11
ae. Prevention of non-delivery notification....................................................................... 2-11
af. Primary and copy recipients indication....................................................................... 2-12
ag. Receipt notification request indication........................................................................ 2-12
ah. Redirection disallowed by originator........................................................................... 2-12
ai. Redirection of incoming messages ............................................................................ 2-12
aj. Reply request indication............................................................................................. 2-13
ak. Replying MM indication.............................................................................................. 2-13
al. Requested preferred delivery method ........................................................................ 2-13
am. Subject indication ...................................................................................................... 2-13
an. Use of distribution list ................................................................................................ 2-13
203. Optional Elements of Service not used in MMHS.............................................................. 2-14
a. Implicit conversion..................................................................................................... 2-14
b. Importance indication ................................................................................................ 2-14
c. Probe......................................................................................................................... 2-14
d. Restricted delivery..................................................................................................... 2-14
e. Return of content ....................................................................................................... 2-14
f. Sensitivity indication .................................................................................................. 2-15
204. Physical Delivery Elements of Service.............................................................................. 2-15
205. Security Elements of Service ............................................................................................ 2-15
206. Message Store Elements of Service ................................................................................. 2-15
a. MS register ................................................................................................................ 2-15
b. Stored message alert................................................................................................. 2-15
c. Stored message auto-forward .................................................................................... 2-16
d. Stored message deletion ........................................................................................... 2-16
e. Stored message fetching ........................................................................................... 2-16
f. Stored message listing............................................................................................... 2-16
g. Stored message summary ......................................................................................... 2-16
SECTION II
ADDITIONAL MILITARY ELEMENTS OF SERVICE
207. Military Elements of Service ............................................................................................. 2-16
a. Primary Precedence .................................................................................................. 2-16
b. Copy Precedence ...................................................................................................... 2-17
c. Message Type ........................................................................................................... 2-17
d. Exempted addresses ................................................................................................. 2-18
e. Extended authorization info ....................................................................................... 2-18
f. Distribution code........................................................................................................ 2-18
g. Message Instructions ................................................................................................. 2-19
h. Clear service ............................................................................................................. 2-20
UNCLASSIFIED XII ORIGINAL

207. (continued)
i. Other recipient indicator............................................................................................. 2-21
j. Originator reference................................................................................................... 2-21
k. Use of Address List.................................................................................................... 2-21
208. Transition Elements of Service ......................................................................................... 2-22
a. Handling instructions ................................................................................................. 2-22
b. Pilot forwarded .......................................................................................................... 2-22
c. Corrections ................................................................................................................ 2-22
d. ACP127 Message Identifier ....................................................................................... 2-22
e. Originator PLAD ........................................................................................................ 2-22
f. Codress message indicator........................................................................................ 2-23
g. ACP 127 Notification Request.................................................................................... 2-23
h. ACP 127 Notification Response ................................................................................. 2-23
CHAPTER 3
MESSAGE HANDLING SYSTEM COMPONENTS
SECTION I
MESSAGE TRANSFER SYSTEM
301. Prohibition of Probes...........................................................................................................3-1
302. Delivery and Non-Delivery Reports .....................................................................................3-1
303. Retention of Other Recipients .............................................................................................3-2
304. Configuration Management.................................................................................................3-2
305. Audit Trail and Logging Requirements ................................................................................3-2
SECTION II
MILITARY MESSAGING USER AGENTS (MM-UA)
306. Storage and retrieval policies..............................................................................................3-3
307. Prohibition of Probes...........................................................................................................3-3
308. Precedence Based Display .................................................................................................3-3
309. Precedence Signaling .........................................................................................................3-3
310. MMS Auto-Actions ..............................................................................................................3-3
a. Auto-discard ................................................................................................................3-3
b. Auto-forward................................................................................................................3-4
c. Auto-acknowledgment .................................................................................................3-4
SECTION III
MESSAGE STORES
312. MS Functional Restrictions .................................................................................................3-5
a. Auto-deletion ...............................................................................................................3-5
b. Auto-forward................................................................................................................3-5
c. Auto-alert.....................................................................................................................3-5
CHAPTER 4
POLICIES AND PROCEDURES
SECTION I
GENERAL PROCEDURES
401. Clear Service......................................................................................................................4-1
402. Recipients...........................................................................................................................4-1
403. Precedence Handling (local) ...............................................................................................4-1
a. Definitions of Precedence Levels.................................................................................4-1
b. Grade of Delivery ........................................................................................................4-2
UNCLASSIFIED XIII ORIGINAL

403. (continued)
c. Determining Precedence .............................................................................................4-2
d. Processing...................................................................................................................4-3
404. Message Acknowledgment..................................................................................................4-3
405. Confirmation of Delivery .....................................................................................................4-4
406. Cancellations ......................................................................................................................4-4
407. Corrections .........................................................................................................................4-4
408. Repetitions, Checks, and Verifications ................................................................................4-5
409. Minimize .............................................................................................................................4-5
410. Message Cache ..................................................................................................................4-5
411. Tracer Action ......................................................................................................................4-5
412. Military Message Bodies .....................................................................................................4-5
a. Sequence of Textual Matter.........................................................................................4-6
b. Multiple Body Parts......................................................................................................4-6
c. Military Body Part Types..............................................................................................4-6
413. Speed of Service ................................................................................................................4-6
a. Speed of Transmission ................................................................................................4-7
b. Speed of Handling .......................................................................................................4-7
414. Duplicate Detection.............................................................................................................4-8
415. Conversion .........................................................................................................................4-8
416. References .........................................................................................................................4-8
417. Use of Alternate Delivery Mechanisms................................................................................4-8
a. Originator Requested Alternate Recipient ....................................................................4-9
b. Redirection of Incoming Messages ..............................................................................4-9
c. Alternate Recipient Assignment ...................................................................................4-9
d. MS Autoforwarding ......................................................................................................4-9
e. UA Autoforwarding..................................................................................................... 4-10
SECTION II
SECURITY
418. Message confidentiality..................................................................................................... 4-10
419. Message integrity.............................................................................................................. 4-10
420. Data origin authentication ................................................................................................. 4-10
421. Access Control.................................................................................................................. 4-10
422. Message Non-repudiation with proof of origin.................................................................... 4-10
423. Message Non-repudiation with proof of delivery ................................................................ 4-11
424. Message Security Labeling ............................................................................................... 4-11
425. Accountability ................................................................................................................... 4-11
426. Prohibition of Probes......................................................................................................... 4-11
427. Security Classification....................................................................................................... 4-11
a. Responsibility ............................................................................................................ 4-11
b. Classifications ........................................................................................................... 4-11
c. Security Label............................................................................................................ 4-12
428. MM and MT EoS Interaction with ACP 120 EoS................................................................ 4-12
a. Alternate Recipient Allowed ....................................................................................... 4-12
b. Blind Copy Recipients................................................................................................ 4-12
c. Clear Service............................................................................................................. 4-12
d. Conversion ................................................................................................................ 4-12
e. Deferred Delivery ...................................................................................................... 4-12
f. Exempted Addresses................................................................................................. 4-13
g. Hold for Delivery........................................................................................................ 4-13
h. Redirection Disallowed by Originator ......................................................................... 4-13
i. Use of Distribution Lists ............................................................................................. 4-13
j. Use of Alternate Redirection Mechanisms.................................................................. 4-13
UNCLASSIFIED XIV ORIGINAL

SECTION III
NAMING AND ADDRESSING
429. O/R Addresses.................................................................................................................. 4-14
430. Directory Names ............................................................................................................... 4-14
431. Address Lists .................................................................................................................... 4-15
a. List Expansion ........................................................................................................... 4-15
b. Owner........................................................................................................................ 4-15
c. Notifications............................................................................................................... 4-16
d. Titles ......................................................................................................................... 4-16
e. Use............................................................................................................................ 4-16
432. Directory Services............................................................................................................. 4-16
SECTION IV
MANAGEMENT
433. Accounting policies and procedures .................................................................................. 4-16
434. Trace and Accountability................................................................................................... 4-17
a. Accountability Requirements ..................................................................................... 4-17
b. Audit Trail Information Management.......................................................................... 4-17
c. Tracer Action ............................................................................................................. 4-17
d. Interdomain Trace Operations ................................................................................... 4-18
435. Performance management................................................................................................ 4-18
a. Transfer Delay........................................................................................................... 4-18
b. Connection Establishment Delay ............................................................................... 4-18
c. Storage Availability.................................................................................................... 4-18
436. Configuration Management............................................................................................... 4-18
CHAPTER 5
PROFILES
SECTION I
TAXONOMY
501. A-profiles ............................................................................................................................5-1
502. B-profiles ............................................................................................................................5-2
503. F-profiles ............................................................................................................................5-2
SECTION II
STANDARD PROFILE
504. Profile Definition .................................................................................................................5-4
505. Implementation Requirements ............................................................................................5-4
Annex A
Military Messaging Content Type ...................................................................................... A - 1
Annex B
MM IO-ICS Proforma ........................................................................................................... B - 1
UNCLASSIFIED XV ORIGINAL
Annex C
STANDARDIZED PROFILE: AMH1n(D)

MHS Service Support.......................................................................................................... C - 1
Appendix A : Elements of Service for ACP 123 ...................................................... C - 11
Specification of ROSE, RTSE, ACSE, Presentation and Session Protocols for use
by MMHS............................................................................................................................ C - 19
Appendix A : SPICS Requirements List – Specific Upper Layer Requirements for
ACSE, Presentation and Session............................................................................ C - 26
Appendix B : SPICS Requirements List for RTSE................................................... C - 28
Appendix C : SPICS Requirements List for ROSE .................................................. C - 29
AMH11(D) – MMHS Requirements for Message Transfer (P1) ........................................ C - 31
Appendix A : SPICS Requirements List for AMH1n(D) Part 3 (AMH11(D)).............. C - 37
AMH12(D) – MMHS Requirements for MTS Access (P3) ................................................. C - 41
AMH13(D) – MMHS Requirements for MS Access (P7) ................................................... C - 51
Annex D
STANDARDIZED PROFILE: FMH11(D)

FMH11(D) - MM Content (P772) .......................................................................................... D - 1
Appendix A : MM Elements of Service...................................................................... D - 9
Appendix B : SPICS Requirements List for FMH11(D)............................................ D - 11
Annex E

FMH20(D) – General MS Attributes .................................................................................... E - 1
Appendix A : SPICS Requirements List for FMH20(D).............................................. E - 7
Annex F

FMH21(D) – MM-specific MS Attributes ..............................................................................F - 1
Appendix A : SPICS Requirements List for FMH21(D)...............................................F - 7
Annex G
Reference Documents......................................................................................................... G - 1
LIST OF EFFECTIVE PAGES
List of Effective Pages .................................................................................................... LEP - 1
List of Figures
Figure 1-1 X.400/ACP 123 Message Structure....................................................................................1 - 4
Figure 1-2 ACP 123 Messaging Environment .....................................................................................1 - 5
Figure 1-3 ACP 123 Management Domain Connections .....................................................................1 - 6
Figure 5-1 Profile Taxonomy ..............................................................................................................5 - 3
UNCLASSIFIED XVI ORIGINAL

CHAPTER 1
GENERAL
SECTION I
INTRODUCTION
a. The function of this document, Allied Communication Publication (ACP) 123, is to define the
services, protocol, and procedures to support electronic messaging for Defense. In so doing the
document expands on X.400 and defines the Military Messaging Elements of Service (EoS), procedures
and protocols. Some guidelines for national implementation of the messaging systems are described.
Minimal criteria to ease interoperability with existing systems through message and protocol gateways
are presented. The aim of ACP 123 is to encapsulate all services, procedures, and protocols for all
Allied X.400 messaging environments into one document.
101. Background
a. This ACP was developed and coordinated under the auspices of the Combined
Communications Electronics Board (CCEB) with the Allied Message Handling (AMH) International
Subject Matter Experts (ISME) working group. This group was organized to develop a common
messaging strategy that can be deployed to facilitate interoperability among the Allies for Military
Message (MM) traffic. The new common messaging strategy, which includes the definition of EoS and a
corresponding set of procedures, is based on the 1992 version of the International Telegraph and
Telephone Consultative Committee (CCITT)1 X.400 Series of Recommendations.
b. This ACP identifies the service and protocol requirements necessary to ensure
interoperability among Military Message Handling Systems (MMHS) for MM traffic that formally commits
an organization and requires authorized release. This ACP specifically does not cover messaging
between individuals. Gateway and transition issues between MMHS and other messaging systems are
out of scope of this ACP. It defines the services that shall be provided and the protocols that shall be
used by MMHS in the Application Layer of the Open Systems Interconnection (OSI) reference model. To
ensure interoperability with North Atlantic Treaty Organization (NATO) members, this ACP was
developed in close coordination with the NATO Tri-Service Group on Communications and Electronics
(TSGCE) Subgroup 9 (SG/9). TSGCE SG/9 is responsible for developing NATO Standardization
Agreements (STANAGs) on data distribution such as STANAG 4406 on MMHS.
c. Annex A is written in the structure and form of the 1992 X.400 series of recommendations,
but contains only the changes and enhancements to the base documents necessary to support Military
Messaging. Consequently, the numbering of paragraphs, figures, and tables in the annex may not
appear to be sequential because the unchanged portions of the base documents are absent. Annex A
has been harmonized with Annex A of NATO STANAG 4406, in order to ensure only one protocol
definition for the support of the MM content type.
1 Note that CCITT was recently reorganized into the International Telecommunications Union -
Telecommunications Standardization Sector (ITU-T). The term CCITT is used here in the
interest of maintaining clarity and continuity with references to existing CCITT documents.
UNCLASSIFIED 1-1 ORIGINAL

102. Evolution
ACP 123 is based on civilian international standards in order to maximize the use of commercial
off the shelf (COTS) products and non-developmental items (NDI). The AMH ISME should monitor the
development of future extensions to these international standards. As extensions become stable and
commercial vendors are likely to adopt them, the group should make a determination whether or not it is
appropriate to add them to ACP 123 within updated versions. If a consistent quality of service is to be
maintained among the Allies, changes to the civilian standards will only become a part of ACP 123 with
formal review and coordination.
103. Scope
a. The fundamental purpose of ACP 123 is to define a common message service to be

provided between all participating nations. This will be achieved by defining the EoS to be provided, the
procedures they support, and a messaging strategy. By accomplishing these tasks, participating nations
avoid the introduction of gateways to translate between different message formats2 and protocols. This
does not, however, preclude national differences for internal messaging.
b. Translation gateways may be required between ACP 123 domains and civilian Message
Handling System (MHS) domains, and will be required between ACP 123 domains and older military
messaging domains (ACP 127 and its supplements). Additionally, gateways at national boundaries may
be necessary due to differences in cryptography or security management issues. Requirements for
these gateways are outside the scope of ACP 123. However, by defining the services to be supported
and a limited set of corresponding procedures, a consistent quality of service should be attained.
c. This ACP identifies the services and protocol requirements for interoperability between
systems implementing the defined service. The focus is on the services to be provided. The procedures
to ensure a consistent quality of service are also specified. The protocol elements used to convey the
service information are also specified when the mechanism to provide the service has been agreed.
d. This ACP pertains primarily to the communication aspects of the messaging application.
Local interfaces and requirements, such as the specifics of terminal display and local storage for archival
purposes are not part of this publication, except where required to ensure interoperability. ACP 123
includes requirements for which information shall be displayed to the user, but the graphical display is
outside the scope of this document.
e. ACP 123 is based on the 1992 CCITT X.400 Series of Recommendations3 (henceforth
referred to as X.400) and adopts the extensions documented in the NATO STANAG 4406. The ACP 123
contains enough information to be read alone by someone familiar with X.400 without duplicating the
majority of the material contained in the X.400 Series of Recommendations. However, pointers to
related information in X.400 are included for those readers requiring more details. Pointers to related
material harmonized with STANAG 4406 refer to Annex A of this document, which contains military
extensions to X.400. These extensions are presented in the form of a delta document to X.400.
2 The term Common Message Format is derived from the current messaging system (ACP 127)
which contains a definition of where information is carried in a message. ACP 127 messages are
a formatted sequence of characters whereas X.400 messages use a formatting technique to
encode information in well-defined data structures. The phrase "Common Message Format" will
not be used with ACP 123 because it is not applicable to X.400 messages.
3 Seven recommendations form the 1992 X.400 Series of Recommendations: X.400, X.402,
X.407, X.408, X.411, X.413, and X.420. Where appropriate, the specific recommendation will be
referenced.

103. (continued)
f. ACP 123 defines the services required in an environment where messages are originated
and received using ACP 123. Nations exchanging MMs using X.400 across national boundaries should
follow the procedures described in this ACP 123 document. Annex A identifies some services and the
related protocol fields that are only required for interworking with older military messaging systems (ACP
127). Interworking with these older systems is outside the scope of this document. Origination of these
transitional services is therefore not required as part of ACP 123. However, it is recognized that many of
these same services will need to be addressed in a transition document.
104. Overview
a. The messaging system employing ACP 123 EoS and related procedures will utilize
internationally available messaging and directory service standards and protocols to provide a totally
automated writer-to-reader messaging system. X.400 will be used for the exchange of messages.
Because of the military environment, some additionally required extensions are specified by ACP 123.
These additional requirements include security, a Military Messaging User Agent (MM-UA), a Military
Messaging Message Store (MM-MS), and a new content type. X.500 will be used for the provision of
directory services. Directory services should be provided to support messaging system functions. It is
recommended that directory services and protocols conforming to the ITU-T X.500 Series of
Recommendations be used. ACP 133 states the directory services for the Allied environment.
b. MMs are composed of X.400 envelopes and Military content type(s). The envelope carries
the information necessary for submission, transfer, and delivery of the message. The envelope is the
same basic envelope as used in the civilian MHS. With the same envelope, commercial Message
Transfer Systems (MTS) may be used to carry MMHS traffic. The content of the message is the
information the originator wishes delivered to one or more recipients. The content of the message will be
a MM content type, which is comprised of extensions to the X.420 International Standard. (See Figure 1-
1)
c. The MMHS will be composed of objects that perform message submission, transfer, and
delivery and provide additional services; the MTS, which is comprised of Message Transfer Agents
(MTAs), will support the transfer of MMs; MM-UAs will support the submission and delivery of MMs;
optional Message Stores (MS) will assist an MM-UA in accepting delivery of messages when the MM-UA
may not be available, and a Directory System to assist the MMHS and the messaging users themselves.
These objects exchange information in the form of formatted Protocol Data Units (PDUs) exchanged
over an OSI communication association. Each of the PDU formats constitutes an Application Layer
protocol. There are three envelope protocols (or PDUs) used by X.400: P1, P3, and P7. The P1 protocol
supports communication between MTAs. The P3 protocol supports access to the MTS, and the
submission and delivery of messages. The P7 protocol supports access to an MS by the MM-UA, and
the indirect-submission and retrieval of messages. Content types, such as P772, are information objects
that are conveyed with the various envelope protocols. (See Figure 1-2)
d. The MMHS Management Domains may be connected to Civilian MHS Management

Domains by way of gateways. During transition from older military messaging systems, gateways
between older MMHS domains (ACP 127) and ACP 123 domains may also be supported. Such
gateways are not defined in this document. The ACP 123 Management Domain within a country may
also connect to ACP 123 Management Domains in other countries. (See Figure 1-3)

MM
Content
Heading
IPMS Heading Fields
MM Extension
Heading Fields
P1
Envelope
Body
Optional Multiple
Body Parts
Figure 1-1 X.400/ACP 123 Message Structure

User
ACP 123 Military Message

MM-UA P7 Handling System (MMHS)
MS
P3 User
Message Transfer System (MTS) P3
MM-UA
MTA
P1
P1 MTA
MS P3
MTA P1
P1
P7
P1
MTA
MM-UA P3
MM-UA
User User
ACP 133 Directory System
Figure 1-2 ACP 123 Messaging Environment

Intercountry
Gateway *
ACP 123 MHS Domain ACP 123 MHS Domain
MM-UA
MM-UA MM-UA MTA
MTA
MTA
MTA
ACP 123/Civilian
MM-UA
Gateway *
MTA
MTA
ACP 127 MTA
Gateway * MM-UA
UA
ACP 127 UA
MS
MTA
Domain
UA
MTA UA
UA
UA MS
UA
Civilian MHS Domain
Country Country
A B Civilian MHS Domain
* = Note that these gateways are expected to be part of the overall system, but are not defined in
this ACP.
Figure 1-3 ACP 123 Management Domain Connections

105. Structure of the Document
a. This ACP is divided into five chapters. The first chapter (this chapter) outlines the
background and scope of ACP 123 and provides an overview of the MMHS. The second chapter defines
all the ACP 123 functions in terms of EoS. Chapter three describes specific requirements on each of the
three MHS components; the MTS, MM-UA and MS. Chapter four defines policies and procedures
associated with the military use of the services provided by MMHS. The fifth chapter defines two MM
profiles: one for standard use, and a second for use with a Military Messaging System (MMS) in a
restricted bandwidth environment.
b. Throughout the main body of this ACP the use of an italic font (e.g., this is italics)
distinguishes the names of specific protocol elements cited from the X.400 syntax definition. These
names are formatted according to Abstract Syntax Notation One (ASN.1) conventions. As such, these
italicized names frequently contain unusual capitalization, hyphens, or missing spaces that are deliberate
features of the ASN.1 name.
c. Seven annexes are included in this ACP. Annex A defines the MM content type and has
been harmonized with the NATO STANAG 4406, in order to ensure only one protocol definition for the
support of the MM content type. Annex B is an Information Object Implementation Conformance
Statement (IO-ICS) proforma that provides clear guidelines for implementors of what the mandatory and
optional support for the protocol elements used to support the MM content type. This annex contains
Appendix A, which can be filled out by an implementor to state exactly what support is claimed by a
particular implementation. Annex C is the profile for Common Unrestricted Messaging which lists the
MMHS requirements additional to those in ISO/IEC ISP 10611. Annex D is the content specific profile
for the MM content which lists procedural requirements on protocol elements an implementation shall
support to claim conformance to the MM content type. Annex E is the profile general MS attributes
which lists the requirements for general MS attributes by MM-UA and MM-MS implementations. Annex F
is the content specific profile for MM MS attributes which lists the requirements, for MM-specific
attributes MM-UA or MM-MS, implementations shall support. Annex G is a list of reference documents
used in developing this ACP.
SECTION II
DEFINITION OF TERMS USED IN THIS PUBLICATION
106. Definitions
This section provides definitions for unique terms and abbreviations used in the rest of the
document. Terms that are already adequately defined in the X.400 series base standards are not
repeated in this section.
a. Abstract Syntax Notation One (ASN.1) – ASN.1 is the notation used to specify an abstract
representation of the information conveyed by the protocol data units exchanged in X.400. (Defined in
International Standards Organization [ISO] 8824.)
b. Access Unit (AU) – The AU is an origination or delivery end point that provides
interconnection between non-ACP 123 compliant users of the MMHS and ACP 123 compliant users.
c. ACP 127 – ACP 127 is a generic designator used to refer to military messaging systems
based on ACP 127 and its related supplements.
d. ADatP-3 – ADatP-3 refers to a class of military messages that have a pre-defined formatted
text designed to convey information for commonly used and mission critical uses. Examples of ADatP-3
messages include Air Tasking Orders, and logistics reports.

106. (continued)
e. Address List (AL) – An AL is a short hand method for addressing a predetermined list of
recipients. An AL can be carried as an ORName on a recipient field or using the address-list-indicator
military heading extension.
f. Copy Recipients – Copy recipients are those recipients of a message who are sent a
message for information purposes only (information addressees).
g. CSP – Common Security Protocol – The CSP is an information object supported by ACP
120 to provide security services for the MMHS. Any message identified with the content type CSP is a
Common Security Protocol message.
h. Directory Name – A directory name is a unique identifier for a record stored in a directory
system. A directory name can be resolved by a directory system into a X.400 OR Address, a set of user
capabilities, or other information. Implementation of a Directory that is X.500 conformant is beyond the
scope of this ACP. (See paragraph 429)
i. Dynamic – Dynamic behavior characterizes the constraints on the use of an element of

protocol. Base standards normally define only minimal constraints on dynamic behavior in order to leave
maximum flexibility to the user. Profiles may impose additional constraints, thus imposing additional
requirements that exceed the base standard. The dynamic classifications used within this document are
as follows:
(1) Optional – the referenced protocol element may be either present or absent at the
discretion of the user (or implementation). This classification is the default requirement normally
assigned by base standards. No dynamic constraints are implied. This classification is never explicitly
included in classification tables because it is the default condition.
(2) Required (r) – the referenced protocol element shall be present in every instance of
communication. Under most circumstances, absence of an element classified as required may be
construed as a protocol violation. The term dynamic mandatory is sometimes used instead of dynamic
required.
(3) Excluded (x) – the referenced protocol element shall never be present in any instance
of communication. Under most circumstances, presence of an element classified as excluded may be
construed as a protocol violation or other error (e.g., security violation). The term dynamic prohibited is
sometimes used instead of dynamic excluded.
j. Elements of Service (EoS) – EoS are abstractions that describe features of a system for
which the user of that system has direct access. In some cases, the "user" of the system may be another
system. For example, the MMS is a consumer of the services provided by the MTS. The X.400
recommendation defines EoS as functional units for the purpose of segmenting and describing message
handling features. EoS do not necessarily relate to protocol elements (see clause 106.x) on a one-to-one
basis.
k. Formal military message – A formal military message is a message sent on behalf of an

organization, in the name of that organization, that establishes a formal commitment on the part of that
organization, and that has been formally released in accordance with the policies of the originating
nation.
l. Gateway – Gateway is generic term that covers both AUs and translation gateways.

106. (continued)
m. MM – Military Message – The MM is an information object supported by ACP 123 that is

used to convey messages between military organizations. Any message identified with the content type
P772 is a Military Message.
n. MM-AU – Military Messaging Access Unit – The MM-AU is a functional object that links
another communication system to the MTS within an MMHS.
o. MM-MS – Military Messaging Message Store – The MM-MS is a functional object that
provides an organization or subscriber with capabilities for military message storage and retrieval. It
provides a user with indirect submission capabilities and accepts delivery of MMs on behalf of that user.
An MM-MS is an X.400 MS that supports retrieval of messages based on the MM-specific MS attributes.
p. MM-UA – Military Messaging User Agent – The MM-UA is a functional object that allows an
organization or subscriber to engage in military message handling. An MM-UA is an X.400 User Agent
(UA) that can generate and receive MMs.
q. MMHS – Military Message Handling System – The MMHS is the messaging system defined
by ACP 123. The purpose of MMHS is to convey MMs among military organizations and individuals.
This document addresses only MMHS in the context of MM traffic that has been approved for release
between military organizations.4
r. MMS – Military Messaging Service – The MMS is a service that provides electronic
messaging to staff units and authorized individual users (i.e., message release authorities) in military
organizations. The MMS fulfills established military requirements for messaging systems.
s. MS – Message Store – The MS is an optional functional object that provides users with
capabilities for message storage and retrieval. It provides a user with indirect submission and accepts
delivery of messages on behalf of the user.
t. Plain Language Address Designator (PLAD) – A PLAD is an abbreviated or non-abbreviated

activity (organization) title with associated geographical location. The PLAD is used in ACP 127
message addressing.
u. Precedence – Precedence is a labeled value that reflects the originator's determination of

the relative message importance and thereby determines the required speed of service and its
associated message handling by the recipient(s).
v. Primary Recipients – Primary recipients are those recipients of a message who have the
responsibility to act on the delivered message (action addressees).
w. Priority – Priority is a labeled value that reflects the required speed of service for a
message. It is synonymous with the Grade of Delivery selection in the message transfer service.
x. Protocol Elements – Protocol elements are well-defined data structures that are transmitted
between open systems to exchange information. The collection of all such protocol elements used for a
particular communication is known as the abstract syntax. Protocol elements do not necessarily relate to
EoS (see clause 106.j) on a one-to-one basis. Protocol elements are sometimes called "protocol fields",
"fields", or "sub-fields".
4 Guidelines for individual traffic shall be clarified in supplements or by bilateral agreements.

106. (continued)
y. Routing Indicator (RI) – The RI is a group of letters assigned to identify a station within a
tape relay network. The RI facilitates the routing of traffic, indicates the status of the station, and may
indicate its geographical area. (Routing Indicators are composed in accordance with the Routing
Indicator Plan described in the ACP 121 series. RIs are used to define the network address of a
Communications Center (COMCEN) serving one or more organizations. It is used for routing purposes
in ACP 127 messaging).
z. Static – Static behavior characterizes the capability of an implementation to support (i.e.,

generate, decode or process) an element of protocol. Base standards normally define what constitutes
support for a particular element. Base standards normally classify static support requirements for
particular protocol elements according to several standardized classifications. Profiles may also impose
additional static requirements on elements that the base standard classifies as optional. The static
classifications used within this document are as follows:
(1) Mandatory (m) – the element or feature is required to be implemented, and shall be
fully supported in conformance with the Specification. An implementation shall be able to generate the
element, and/or receive the element and perform all associated procedures (i.e., implying the ability to
handle both the syntax and semantics of the element) as relevant, as specified in the MM base
standards. Where support for origination (generation) and reception are not distinguished, then both
capabilities shall be assumed.
(2) Optional (o) – the capability may be implemented, and if it is implemented it is required
to conform to the Specification. An implementation is not required to support the element. If support is
claimed, the element shall be treated as if it were specified as mandatory support. If support for
origination is not claimed, then the element is not generated. If support for reception is not claimed, then
an implementation may ignore the element on delivery, but will not treat it as an error.
(3) Conditional (c) – the requirement on the capability depends on the selection of other
optional or conditional items; the element shall be supported under the conditions specified in this
information object ICS. If these conditions are met, the element shall be treated as if it were specified as
mandatory support. If these conditions are not met, the element shall be treated as if it were specified as
optional support (unless otherwise stated).
(4) Out of scope (i) – the element is outside the scope of this information object ICS – i.e.,
it will not be the subject of an ICS conformance test.
(5) Not applicable (–) – in the given context the base Specification makes it impossible to
use this capability.
aa. Translation Gateway – A translation gateway is a component that translates between

protocols used on different networks in order to support interworking between users of the different
networks.
ab. UA – User Agent – The UA is a functional object that allows a user to engage in message
handling.
UNCLASSIFIED 1 - 10 ORIGINAL
106. (continued)
ac. X.400 – X.400 is a generic designator used in this document to refer to the international
civilian standards, both the CCITT5 X.400 Series of Recommendations and the corresponding ISO/IEC
10021 series (MOTIS).
ad. X.500 – X.500 is a generic designator used in this document to refer to the 1993
international civilian standards, both the ITU-T X.500 Series of Recommendations and the corresponding
ISO/IEC 9594 series.
107. Abbreviations
ACP Allied Communication Publication

ACSE Application Control Service Element
ADatP Allied Data Publications
AIG Address Indicator Group
AL Address List
ALI Address List Indicator
AMH Allied Message Handling
ASE Application Service Element
ASN.1 Abstract Syntax Notation One
AU Access Unit
BER Basic Encoding Rules
CAD Collective Address Designator
CCEB Combined Communications Electronics Board
CCITT International Telegraph and Telephone Consultative Committee6
COMCEN Communications Center
COTS Commercial Off The Shelf
DL Distribution List
DTG Date Time Group
EIT Encoded Information Type
EoS Element of Service
IA5 International Alphabet No. 5
IO-ICS Information Object Implementation Conformance Statement
IP Interpersonal
5 Note that CCITT was recently reorganized into the ITU-T. The term CCITT is used here in the
6 Note that CCITT was recently organized into the ITU-T. The term CCITT is used here in the
107. (continued)
IPM Interpersonal Message

IPMS Interpersonal Messaging System
ISME International Subject Matter Experts
ISO International Organization for Standardization
ISP International Standardized Profile
ITU-T International Telecommunications Union - Telecommunications Standardization Sector
MD Management Domain
MH Message Handling
MHS Message Handling System
MM Military Message
MMHS Military Message Handling System
MMS Military Messaging System
MM-AU Military Messaging Access Unit
MM-MS Military Messaging Message Store
MM-UA Military Messaging User Agent
MOTIS Message Oriented Text Interchange System
MPDU Message Protocol Data Unit
MS Message Store
MT Message Transfer
MTA Message Transfer Agent
MTS Message Transfer System
MTSE Message Transfer Service Element
NATO North Atlantic Treaty Organization
NDN Non-Delivery Notification
NRN Non-Receipt Notification
OR Originator/Recipient
P1 Message Transfer Protocol
P3 Submission and Delivery Protocol
P7 Message Store Access Protocol
P772 Military Messaging Protocol (defined in Annex A)
PDAU Physical Delivery Access Unit
PDS Physical Delivery Service
PDU Protocol Data Unit
PER Packed Encoding Rules
107. (continued)
PLAD Plain Language Address Designator

RI Routing Indicator
ROSE Remote Operation Service Element
RTSE Remote Transfer Service Element
SIC Subject Indicator Code
STANAG (NATO) Standardization Agreement
UA User Agent
USMTF U.S. Message Text Format
UTC Coordinated Universal Time
UA User Agent
X.400 CCITT Series of Recommendations on Message Handling Systems
X.500 CCITT Series of Recommendation on Directory Services
(Reverse Blank)
CHAPTER 2
MESSAGE SERVICES – ELEMENTS OF SERVICE
a. This chapter describes, in X.400 terminology, the services provided by the ACP 123 MMHS.
The first section lists the Basic X.400 EoS supported by the MMHS with references to their definitions in
Annex B of X.400. The second section lists the definition of additional EoS needed in a military
environment. These services, also defined in Annex A to STANAG 4406, contain a reference to their
definition in Annex A of this document. Transitional EoS, which facilitate interoperability with existing
military messaging systems (ACP 127), are grouped in a separate paragraph.
b. When an X.400 service is to be provided, it will be carried in the corresponding ASN.1

protocol element as defined in X.400. When a service is required in the MMHS context and does not fit
one of the X.400 EoS or the EoS does not exist, a new service is defined. New services will be carried in
new protocol elements. The description in section two of this chapter includes the purpose of the new
EoS, the policies and procedures for the use of that service, as well as the field, and possible values to
be used. A reference to the ASN.1 definition of the field in Annex A is included. ASN.1 definitions that
describe the structure of the MM information objects (i.e., the MM content type) are found in Annex A.
When appropriate, the import feature of ASN.1 is used to point to those protocol definitions that are
already defined in the international base standards; therefore, the imported protocol definitions are not
duplicated herein.
c. Requirements for the support of the X.400 and MM EoS in the MMHS are included in this
document. In general, if a service is to be made available in the MMHS then the protocol elements
supporting that service are statically mandatory. This means implementations claiming to conform to the
MMHS requirements shall implement the necessary protocol to support these services. Actual use on a
particular message may be a user option, making the service, and therefore its supporting protocol
elements, dynamically optional (i.e., the service and corresponding protocol elements are mandatory for
an implementation). If the description of an EoS says it shall be supported as a user option, then there is
a requirement that the user interface allow an originator to select that EoS and specify the information to
be carried as part of that service. If the description says that information in support of an EoS is to be
prominently displayed to the user, then this information is to be displayed without requiring the user to
issue additional commands to find that information.
SECTION I
MM ELEMENTS OF SERVICE ADOPTED FROM IPMS
a. EoS are associated with the various functions provided by the MHS and in particular by the
military interpretation of the MHS. The following is a list of these EoS. Where there are no additional
requirements imposed by military messaging over what is defined in X.400, a short description is
included with the name of the EoS, the type of service (i.e., Message Transfer or Military Messaging),
and a reference to its definition in X.400. If an EoS is said to be supported, this means it shall be
implemented by all systems supporting MMHS. Support for an EoS is as defined in X.400, unless
additional requirements are stated here. An example of additional requirements might include the
specification for display to the user.
201. Basic X.400 Elements of Service
The Basic X.400 EoS make use of the MTS and enable a user to send and receive MMs. All
X.400 Basic EoS shall be supported.

201. (continued)
a. Access Management
This MT element of service enables an MM-UA and an MTA to establish access and
manage information associated with access establishment. This includes the ability to identify and
validate the identity of the other. Secure Access Management will be used in the MMHS context. Actual
security mechanisms used to provide secure access management will be defined by national policy.
Strong authentication in the bind operation is mandatory; however, the mechanism is beyond the scope
of this document. (See X.400 B.1, X.400 B.79)
b. Content type indication
This MT element of service enables an originating UA to indicate the content type of each
submitted message. Recipient UAs may be able to accept delivery of one or more content types.
Examples of content type are the Interpersonal Messaging System (IPMS) contents generated by IPM
UAs or the MM contents generated by MM-UAs. MMs will have a content type designated as P772
defined herein. The MM content type will be identified with an object identifier. There is no requirement
to display a specific content type indicator to the user. In most cases, the content type will be obvious
from the heading information that is present. (See X.400 B.12)
c. Converted indication
This MT element of service enables the MTS to indicate to each recipient UA (i.e., on per-
recipient basis) that the MTS performed conversion on the EIT(s) within a delivered message. Security
requirements and mechanisms may not allow conversion to take place within the MTS. However,
messages entering the MMHS network from a gateway (e.g., a civilian X.400 domain, an ACP 127
tactical gateway) may carry the converted indication. If this indication is present on a message, it shall
be displayed to the user. (See X.400 B.15)
d. Delivery time stamp indication
This MT element of service indicates to each recipient UA (i.e., on a per-recipient basis),

the date and time at which the MTS delivered a message to the MS or UA. This time, carried as
Coordinated Universal Time (UTC) time, will be used for audit logging and tracing purposes. This time
stamp shall be displayed to the user. (See X.400 B.22)
e. MM identification
This MM element of service enables cooperating UAs to convey a globally unique identifier
for each MM sent or received. This identifier is used in subsequent messages to identify the original
MM. The IPMIdentifier will contain the ORName of the originator plus a printable string containing a
serial number and the UTC time, specified down to the seconds, indicating the filing time of the
message. This field shall always be present and shall be displayed to the user. (See X.400 B.37, Annex
A B.37)
f. Message identification
A unique identifier provided, as an MT element of service, by the MTS to a UA for each

message submitted or delivered by the MTS. This identifier is used by UAs and the MTS to refer to a
previously submitted message in connection with EoS such as delivery and non-delivery notification.
This identifier will be used internally within the MMHS system. Unlike the MM Identification EoS, there is
no requirement for users to see this field. This identifier will be used for audit logging and tracing
purposes. (See X.400 B.41)

201. (continued)
g. Non-delivery notification
This MT element of service allows the originator to ask, on a per-recipient basis, for the
MTS to notify the originator if a submitted message was not delivered to the specified recipient UA(s).
The MMHS must, with a high degree of certainty, deliver a message to the intended recipient(s). If the
system cannot deliver a message within a determined period of time (See 4.I.413), a non-delivery report
will be returned to the originating UA by the MTS. The non-delivery report contains information to enable
it to be mapped to the appropriate message (i.e., the message identification), recipient information, as
well as information about why the message could not be delivered. Receipt of the non-delivery report
will then cause the UA to generate a non-delivery notification to alert the originator. The information
conveyed in the report must be displayed to the originator in a manner that easily allows the user to
identify the associated message. (See X.400 B.47)
h. Original encoded information types
This MT element of service enables the originating UA to indicate both to the MTS and the
recipient UA the EITs of a message being submitted. The EITs identify the various formats of the body
parts of a message (e.g., IA5, G3-fax, etc.). See the Typed Body EoS below for display requirements.
(See X.400 B.54)
i. Submission time stamp indication
This MT element of service enables the MTS to indicate to the originating UA and each
recipient UA the date and time at which a message was submitted to the MTS. This time, carried in UTC
time format, will be used for audit logging and tracing purposes. The user will be able to request this
time be displayed for a given message. (See X.400 B.89)
j. Typed body
This MM element of service permits the nature and attributes of the body of the message to
be conveyed along with the body. If the type of the body is important to provide context for the
message, it must be displayed to the user. For example, the distinction between Allied Data Publication
3 (ADatP-3) messages and a particular national message text format (e.g., USMTF) might be important
to the recipient. Indication of an IA5 body, however, may not be necessary. (See X.400 B.90)
k. User/UA Capabilities Registration
This MT element of service enables a UA to indicate to its MTA, through registration, the
unrestricted use of any or all of the following capabilities with respect to received messages:
– the content type(s) of messages it is willing to accept;

– the maximum content length of a message it is willing to accept; and
– the EIT(s) of messages it is willing to accept.
The MTA will not deliver to a UA any messages that either exceed or do not match the capabilities
registered. Military messaging requires registration of security contexts be done by external trusted
management means. The mechanisms to support registration may be defined by national or local
policy. This functionality is also supplied by Directory Services defined in ACP 133. (See X.400 B.93,
Annex A B.93)

202. Optional Elements of Service
If a service is optional in this ACP, it is up to the implementation whether the service is available
to the user. If a service is said to be a user option, it shall be implemented, however, it will only be
selected for a given message according to the originator's requirements for a given message. Support
for most of the applicable X.400 services on reception is mandated by the base standard.
a. Alternate recipient allowed
This MT element of service enables an originating UA to specify that the message being
submitted can be redirected or delivered to an alternate recipient. Unless an originator specifically
requests that an alternate recipient not be allowed (see 202.ah), all MMHS messages will indicate that an
alternate recipient is allowed. User interface support for requesting selection or de-selection of this
service is required. (See X.400 B.3)
b. Alternate recipient assignment
This MT element of service enables a UA to be given the capability to have certain

messages delivered to it for which there is not an exact match between the recipient OR Address
attributes specified and the OR Address of the user. Such a UA is specified in terms of one or more OR
Address attributes for which an exact match is required, and one or more attributes for which any value is
acceptable. This service allows a message that would otherwise be undeliverable to be delivered to a
"default mailbox" within the recipient MD. This could be used to guarantee delivery to a responsible
entity in cases where a minimum set of OR Address attributes is specified for the intended recipient.
Alternate Recipient Allowed would have to be selected by the originating UA to enable this service for a
given message. See clause 417 for security issues related to the Alternate Recipient Allowed EoS. Due
to security implications, the mechanisms for providing this service will be dependent on national policy.
(See X.400 B.4)
c. Authorizing users indication
This MM element of service allows the originator to indicate to the recipient the names of
one or more persons who authorized the sending of the message. This field is used to convey
information from originator to recipient only. There is no associated security mechanism for obtaining
"proof of authorization". This service will be used to convey the OR Descriptor of the release authority
for the message for information only. This service shall be supported as a user option. If this service is
present, it shall be displayed to the recipient. (See X.400 B.5)
d. Auto-forwarded indication
This MM element of service allows a recipient to determine that the body of an incoming
message contains a message that has been auto-forwarded. This is to distinguish it from a message that
may contain a body part that was manually forwarded by its original recipient. The requirement to
support this service on origination is conditional on other areas such as security policy, use of MS, etc.
and will be determined by local or national policy. If autoforwarding is supported then, this indication
shall be supported on origination. However, if the indication is present, it shall be displayed to the
recipient. (See X.400 B.6)
e. Blind copy recipient indication
This MM element of service enables the originator to provide the OR Descriptor of one or
more additional intended recipients (i.e., on a per-recipient basis) of the message being sent. These
names are not disclosed to the primary, copy, or other blind copy recipients. This service shall be
supported as a user option. This service can be used to keep some recipient names and addresses
hidden from some of the other recipients. This service, when supported, will be a user option and can be

202.e (continued)
used to send a courtesy copy to drafters or reviewers of a message, when internal information such as
who drafted or reviewed the message is not to be disclosed to the recipient(s). Separate copies of the
message shall be submitted to the MTS for open recipients (primary and copy recipients) and for each
blind copy recipient. The IPMIdentifier of the of the blind copy message(s) shall be identical to the
IPMIdentifier of the message submitted to the MTS for the primary and copy recipients. If the recipient is
a blind copy recipient, an indication shall be prominently displayed to the user. (See X.400 B.8)
f. Body part encryption indication
This MM element of service allows the originator to indicate to the recipient that a particular
body part of the message being sent has been encrypted. The methods for encrypting and decrypting
that body part are outside the scope of X.400 and this ACP. Bilateral agreements concerning the
algorithm used for encryption and decryption must be agreed upon by the originator and recipient(s)
before this service is used. Support for originating the encrypted indication shall be optional. However,
if the indication is present, it shall be displayed to the recipient. (See X.400 B.9)
g. Conversion prohibition
This MT element of service enables an originating UA to instruct the MTS that implicit
conversion of EIT(s) should not be performed on this message. Support of this service is mandatory in
cases where conversion could impact security for a given message. If security services are used such
that a particular message is encrypted, the MTS is not likely to have the information necessary to
perform implicit conversion. Enabling the Conversion Prohibition EoS is an added precaution, and shall
be supported as a user option. (See X.400 B.13)
h. Conversion prohibition in case of loss of information
This MT element of service enables an originating UA to instruct the MTS that implicit
conversion of encoded information type(s) should not be performed on this message, if such
conversion(s) would result in loss of information. The specifics of what constitutes loss of information
are discussed in detail in X.408. If both Conversion Prohibition and Conversion Prohibition In Case Of
Loss Of Information are present on a message, Conversion Prohibition takes precedence and no
conversion will be permitted unless Explicit Conversion was also requested. This service shall be
supported as a user option when the ability to request Explicit Conversion is also supported. Selection of
conversion prohibition may stop delivery of a message to a recipient who is located beyond an interface
point (e.g., a recipient in a tactical environment). See 4.I.415 for additional security implications. (See
X.400 B.14)
i. Cross-referencing indication
This MM element of service allows the originator to associate the globally unique identifiers
of one or more other messages with the message being sent. This enables the recipient's UA, for
example, to retrieve from storage a copy of the referenced messages. This service will also be used to
indicate partial corrections to earlier messages. This service shall be supported as a user option. If
present, this indication shall be displayed to the user. If the originator requires a label for easy reference
to multiple cross references in the text of this message, or if other types of referenced material (e.g., a
document, ACP 127 message, etc.) are used, then a reference list will be included in the body of the
message. In this case the originator will include the word "Reference" and a list of the references
labeling each with a short-hand label (e.g., A, B, C, etc.) at the top of the body requiring the references.
See 4.I.416. (See X.400 B.18)

202. (continued)
j. Deferred delivery
This MT element of service enables an originating UA to instruct the MTS that a message
being submitted shall be delivered no sooner than a specified date and time. This would conflict with the
speed of service requirements if the clock starts from the time a message is submitted to the MTS.
Therefore, if Deferred Delivery is requested, time for speed of service requirements starts when the
message leaves the originating MTA, rather than starting at submission time. Support for this service is
optional. When this service is requested, it must be logged for audit and tracing purposes. (See X.400
B.19)
k. Deferred delivery cancellation
This MT element of service enables an originating UA to instruct the MTS to cancel a

previously submitted message that employed the Deferred Delivery EoS. The cancellation attempt may
not always succeed. If the cancellation fails, other methods such as the Obsoleting Indication EoS (See
2.I.202.ab) may be used to nullify the message. National supplements may choose to require that
messages be held at the originating MTA in order to better support this service. Support for Deferred
Delivery Cancellation is conditional. If Deferred Delivery is supported, Deferred Delivery Cancellation
shall be supported. (See X.400 B.20)
l. Delivery notification
This MT element of service enables an originating UA to request that the originating UA be

explicitly notified when a submitted message has been successfully delivered to a recipient UA or Access
Unit (AU). This notification is conveyed by the delivery report. The delivery report is related to the
submitted message by means of the message identifier and includes the date and time of delivery.
Receipt of a delivery report at the originating UA results in the generation of a delivery notification to the
originator. In the case of multi-destination messages, this service shall be selectable on a per-recipient
basis. In the case of recipients specified by an Address List (AL), the policies of the AL will determine
whether the notifications are returned to the originator, the owner of the AL, or both. This notice is for
information only. It does not imply the message has been seen by the recipient, only that it has left the
MTS. If other means of message acknowledgment have been requested (e.g., Receipt Notification
Requested or Reply Requested) the delivery notification should not be requested (see 4.I.404 and
4.I.405). The ability to request return of delivery notifications shall be supported as a user option. The
ability to return a delivery report when delivery notification is requested shall be supported. (See X.400
B.21)
m. Designation of recipient by directory name
This MT element of service enables an originating UA to use, on a per-recipient basis, a

directory name in place of an individual recipient's OR Address. This implies support of a Directory. The
directory name must be translated to an OR Address for delivery to take place within the MTS.
However, the directory lookup may take place at the MTA rather than at the UA level. This service is
optional. If support of this service is claimed the point at which the name is translated to an OR Address
may be defined by national policy or international agreement. Support for this service means if a
directory name is present in a message it can be displayed to the recipient. It does not imply all
originators will be able to specify a directory name for all recipients. Not all users will necessarily be
assigned directory names. Unless an establishment of a global directory system is agreed to by all
participating management domains, originators may only be able to specify directory names for those
recipients that are registered in the directory maintained by the originating MD. Exceptions may be
possible by bilateral agreement. (See X.400 B.24)

202. (continued)
n. Disclosure of other recipients
This MT element of service enables the originating UA to instruct the MTS to disclose the
OR Names of all other recipients of a multi-recipient message to each recipient UA, upon delivery of the
message. The OR Names disclosed are as supplied by the originating UA and come from the P1
envelope of the message. If an AL is used, only the AL name is disclosed, not the names of the
members of the list. This information is provided to the UA. Not all user interfaces will display recipient
information that was not contained in the content recipient information. Recipient information that the
originator wants to be displayed to the recipient should be carried in the content heading of the message.
This service is optional. (See X.400 B.25)
o. DL expansion history indication
This MT element of service provides to a recipient, upon delivery, information about the
DL(s) that brought the message to this recipient. This service shall be supported in the MTS in order to
protect against potential nested DL looping. On reception, the information must be correctly handled by
the UA if it is present, and shall be able to be displayed to the user. (See X.400 B.26)
p. DL expansion prohibited
This MT element of service allows an originating user to specify that if any of the recipient
names can directly, or by reassignment, refer to a DL, then no expansion shall occur. Instead, a non-
delivery notification will be returned to the originating UA. Reassignment refers to any means of
redirection (e.g., alternate recipient or redirection of incoming messages). In a security conscious
environment, originators should know if the addresses they use are DLs, although this might not always
be the case if recipient reassignment can take place. This service shall be supported as a user option.
(See X.400 B.27)
q. Expiry date indication
This MM element of service allows the originator to indicate to the recipient the date and
time after which the message is considered invalid. The intent of this element of service is to state the
originator's assessment of the current applicability of a message. Use of this service is a user option. If
this indication is present, it shall be displayed to the recipient(s) to indicate the time after which this
message should no longer be acted upon. It is left to the discretion of the recipient whether or not the
message is discarded. Messages containing an Expiry date indication will not be automatically deleted
from a recipient's message storage when the expiration time has passed. This EoS procedurally
excludes auto-discard and deletion actions (see 3.II.310.a and 3.III.312.a). Instead, the user interface
will display the expiration date and time indicated to the recipient when the message is accessed. It is
the responsibility of the recipient to discard the message after the expiration time. (See X.400 B.29)
r. Explicit conversion
This MT element of service enables an originating UA to request, on a per-recipient basis,

that the MTS perform a specified EIT conversion, such as required when interworking between different
Telematic Services. In a secure environment, the information necessary to perform conversion is
unlikely to be available to the MTS. Therefore, support for this service is optional in the MMHS
environment. (See X.400 B.30)
s. Forwarded MM indication
This MM element of service allows a message, plus its delivery information, to be sent as a
body part inside another message. In a multi-part body, the forwarded message may be one of several

202.s (continued)
body parts of various types. A externally defined body part type called mm-message-body-part is
defined in Annex A. Support for this body part is mandatory. An MM may contain both Forwarded-MM
and Forwarded-IP messages. (See X.400 B.31)
t. Grade of delivery selection
This MT element of service enables an originating UA to request that transfer through the
MTS take place at a selected priority. The time periods defined for each grade of delivery must be
specified by policy. The delivery time requirements are goals. National or other policy must define the
level of assurance to meet the goals. (See 4.I.413) An indication of the grade selected is sent to the
recipient UA with the delivered message. The supporting protocol element, priority, is dynamically
mandatory. Support for this service is mandatory. Grade of Delivery will always be used in the MMHS
because the value of the priority field will be derived from the Primary Precedence selection. If a
Message Protocol Data Unit (MPDU) has no primary recipients, and therefore no Primary Precedence,
the priority value will be derived from the Copy Precedence. In the case of an MPDU with neither
primary nor copy recipients (i.e., a Blind Copy recipient's copy of a message), the priority value will be
NON-URGENT. The Grade of Delivery shall not be displayed to the recipient, because they will get
more information by seeing the Primary and Copy Precedence. (See X.400 B.32)
u. Hold for delivery
This MT element of service enables a recipient UA to request that the MTS hold its
messages and returning notifications of delivery until a later time. The UA indicates to the MTS when it
is unavailable to take delivery of messages and notifications, and also, when it is again ready to accept
delivery from the MTS. The MTS can indicate to the UA that messages are waiting due to the criteria
the UA established for holding messages. Responsibility for the management of this element of service
lies with the recipient MTA. Criteria for requesting that messages be held are:
– EIT,
– content type,
– maximum content length, and
– priority.
This service differs from the function of the MS, providing temporary storage only. Delivery reports are
not returned until after a message is transferred to the recipient UA. If the maximum delivery time
expires while a message is being held it will be Non-delivered. Support for this service is optional. The
requirement to utilize this service will depend on specific configuration employed, which may be dictated
by national policy. When Hold for Delivery is supported, there must be a method for ensuring delivery to
a backup recipient all messages with a priority value of URGENT (i.e., FLASH and OVERRIDE
precedence) in order to ensure timely delivery. Possible mechanisms for achieving this backup delivery
include certain uses of Auto-forwarding, Redirection of Incoming Messages, or Originator Requested
Alternate Recipient. (See X.400 B.33)
v. Incomplete copy indication
This MM element of service allows an originator to indicate that this message is an

incomplete copy of a message with the same IPMIdentifier in that one or more body parts or heading
fields of the original message are absent. This service might be useful in limited bandwidth
environments. For example if a tactical message is defined with limited heading fields, at the gateway
between the restricted and standard environments, the message could be stripped to the tactical fields
only and incomplete copy indicated. Another use of this indication might be with a multi-body part
message where only some of the body part types are acceptable to a given UA. Use of this service, and

202.v (continued)
determination of which fields can be left out, needs to be clarified by national or local policy. This
service shall be supported as a user option. If this indication is present, it shall be displayed to the user.
(See X.400 B.36)
w. Language indication
This MM element of service enables an originating UA to indicate the language type(s) of a

submitted message. This service shall be supported as a user option. If this indication is present, it shall
be displayed to the user. (See X.400 B.38)
x. Latest delivery designation
This MT element of service enables an originating UA to specify the latest time by which the
message is to be delivered. If the MTS cannot deliver by the time specified, the message is canceled
and a non-delivery report returned. In a multi-recipient message, this will not negate deliveries that may
already have occurred. In an instance of the user invoking the latest delivery designation EoS, the UA
shall display a warning to remind the user that use of the service may result in non-delivery of a
message. This service shall be supported as a user option. (See X.400 B.39)
y. Multi-destination delivery
This MT element of service allows an originating UA to specify that a message being

submitted is to be delivered to more than one recipient UA. This does not imply simultaneous delivery to
all specified recipient UAs. This service shall be supported as a user option. (See X.400 B.45)
z. Multi-part body
This MM element of service allows an originator to send a message that is partitioned into
several parts. The nature and attributes, or type, of each body part are conveyed along with the body
part. This enables the multiple parts to be of different encoded information types. This service shall be
supported as a user option. (See X.400 B.46)
(1) Transmission of ADatP3 formatted messages shall use the adatp3-body-part type.
This body part type allows the user to convey formatted message data in either a linear (line-oriented) or
columnar (set-oriented) format in accordance with Allied Data Publication 3 (ADatP3). It will also carry
an optional message sequence reference number in the body part's parameters. Support of the adatp3-
body-part is mandatory.
(2) In cases where a CSP message must be forwarded intact to a new ACP 123 recipient
(e.g., autoforwarding by a MS) the forwarded-CSP-Message-Body-Part type shall be used. The body
part conveys the entire received content as a structured data element. Additionally, it allows the
forwarder to include the majority of the message delivery envelope (minus the message-delivery-
identifier field). When messages are protected by the security services in ACP 120, support of the
forwarded-CSP-Message-Body-Part is mandatory.
(3) Any document exchange between users shall use the file-transfer-body-part type.
The parameters of this body part shall use the external document’s object identifiers. The parameters of
the body part shall be carried in the document-type-name subfield of the contents-type Parameter to
describe the data that is being transferred. These object identifiers may be found in the Electronic Mail
Association (EMA) Message Attachment Work Group (MAWG) Feasibility Project Guide. Support for the
file-transfer-body-part is mandatory.

202.z (continued)
a. Transmission of Data Pattern traffic using ACP 123 shall use the file-transfer-
body-part type. The Data Pattern messages shall be carried as an external data type described by the
id-acp123us-filetransfer-datapattern object identifier. The object identifier shall be present in the
document-type-name subfield within the contents-type parameter. The data shall be carried in the body
part as an octet string and each body part shall contain only one octet string. The Parameter field, if
present in the document-type-name, shall be used to convey the record count as an integer with a default
of zero. Support of this file-transfer-body-part external data type is optional.
b. Transmission of Electronic Data Interchange (EDI) transaction sets using ACP

123 shall use the file-transfer-body-part type. The EDI transactions shall be carried as an external data
type described by X.435-defined object identifiers listed below. The cited object identifiers shall be
present in the document-type-name subfield within the contents-type parameter. The data shall be
carried in the body part as an octet string and each body part shall contain only one octet string. The
Parameter field, if present in the document-type-name, shall be ignored. Support of these file-transfer-
body-part external data type is optional.
– id-bp-edifact-ISO646
– id-bp-edifact-T61
– id-bp-edifact-octet
– id-bp-ansiX12-T61
– id-bp-ansiX12-octet
– id-bp-ansiX12-ebcdic
– id-bp-untdi-ISO646
– id-bp-untdi-T61
– id-bp-private-octet
– id-bp-undefined-octet
aa. Non-receipt notification request indication
This MM element of service allows the originator to ask, on a per-recipient basis, for
notification if the message is deemed unreceivable. Non-receipt notification (NRN) message would be
issued on any of the following events:
– the recipient's UA auto-forwards the message to another user,

– the recipient's UA discards the message prior to receipt,
– the recipient's subscription is terminated before receipt of the message.
The recipient's failure to access the message for a long period of time does not constitute non-receipt.
Support for requesting NRN shall be a user option. Support for the ability to generate an NRN shall be
available if any of the conditions for non-receipt can occur. Which of these events caused non-receipt is
conveyed to the originator in the NRN. If the implemented system supports Auto-forwarding, it shall also
be able to generate NRNs. Likewise if an implementation automatically deletes messages that have
expired or been obsoleted or can terminate a user's UA (mail service) with delivered but not received
messages, then it shall also support generation of NRNs. (See X.400 B.48)

202. (continued)
ab. Obsoleting indication
This MM element of service allows the originator to indicate to the recipient that one or
more previously sent messages are obsolete. This service will be used to provide a way for originators
to cancel previously transmitted messages. Messages containing an obsoleted indication will not
automatically cause the deletion of the obsoleted message from a recipient's message storage. This
EoS procedurally excludes the auto-discard and the auto-deletion actions (see 3.II.310.a and 3.III.312.a).
Instead, when the original message is accessed, the user interface will display information advising the
recipient that the message is obsolete. It is the recipient's responsibility to discard the obsoleted
message if it is still in the current message storage of the MM-UA. This service shall be supported as a
user option, but if this service is supported automatic correlation of the obsoleted message and the
obsoleting message shall be performed. Any local processing used to facilitate automated correlation of
these messages is beyond the scope of this ACP. If this indication is present it shall be displayed to the
user. (See X.400 B.52)
ac. Originator indication
The intent of this MM element of service is to convey to the recipient the identity of the
originator in a user-friendly way. In contrast, the MTS provides the recipient UA the actual OR Address
and directory name, if present, of the originator. Within the MMHS, when the originator field is present, it
should include the directory name (if one is available) in the formal-name sub-field. This additional
requirement is to encourage the use of a user-friendly method for identifying the originator. The free-
form-name or telephone-number sub-fields may also be present. This service shall be supported. When
this indication is present it shall be displayed to the user. (See X.400 B.55)
ad. Originator requested alternate recipient
This MT element of service enables the originating UA to specify, for each intended
recipient, one alternate recipient to which the MTS can deliver the message, if delivery to the intended
recipient is not possible. If the intended recipient has requested the Redirection of Incoming Messages
EoS, and the originating UA has requested that redirection be allowed, the system first tries to redirect
the message to the recipient's designated alternate. If this fails, the system then attempts to deliver the
message to the originator's designated alternate recipient. This service, like Alternate Recipient
Assignment or Redirection of Incoming Messages, may impact security mechanisms. Security
information to enable delivery to the specified alternate must be included in the message being
transmitted. The presence of this service is required in any implementation, but the way in which
alternate recipients are used shall be determined by security or local policy. If the message is delivered
to an alternate recipient, the intended recipient shall be displayed to the user. (See X.400 B.56)
ae. Prevention of non-delivery notification
This MT element of service enables an originating UA to instruct the MTS not to return a
non-delivery report to the originating UA in the event that the message being submitted is judged
undeliverable. This can be requested on a per-recipient basis. This service does not prevent a non-
delivery report from being returned to the originating MTA. The service thereby prevents a Non-delivery
Notification (NDN) from being presented to the originating user. This service shall be a user option for
some precedence levels. Precedence levels of IMMEDIATE and above require that any associated
NDNs be returned to the originator. When this service is requested it will be logged for audit and tracing
purposes. (See X.400 B.61)

202. (continued)
af. Primary and copy recipients indication
This MM element of service allows the originator to provide the names of users or ALs who
are the intended primary recipients and the intended copy recipients of the message. It is intended to
enable the recipient to determine the category in which each of the specified recipients was placed. An
indication of the primary versus copy designation of the recipient shall be displayed to the user. This
service supports the identification of Action versus Information recipients and shall be supported.
Primary recipients have responsibility to act upon the delivered message, while Copy recipients have no
explicit action responsibility and are sent the message merely for information purposes. When a
recipient views a message, the indication of whether that user is categorized as Primary or Copy shall be
prominently displayed. It may be necessary for the user to take some action to see the entire list of all
Primary and Copy recipients. (See X.400 B.62, Annex A B.62)
ag. Receipt notification request indication
This MM element of service allows the originator to ask, on a per-recipient basis, for
notification when the message being sent is received. X.400 allows a recipient UA to respond to the
Receipt Notification (RN) request either automatically or by manual instruction of the user. In addition, it
is permissible for a recipient UA to allow the user to ignore the request for RN. In the MMS the RN will
not be generated until the recipient has viewed the entire message indicating acceptance of
responsibility. In cases where multiple body parts are present the first text body part, which should
contain an overview of the entire body, must be viewed to constitute receipt. (See 4.I.412.b) This
service shall be supported as a user option. If an RN has been requested, this shall be prominently
displayed to the user and the recipient will be required to honor the request to return a RN unless a more
explicit response such as a reply is sent in its place (see 4.I404 and 4.I.405). This EoS procedurally
excludes the use of MMS auto-acknowledgments (see 3.I.309.c). Originators who generate messages
for which a receipt is critical shall use the CSP Request for Signed Receipt function (see ACP 120
2.204). (See X.400 B.67, Annex A B.67)
ah. Redirection disallowed by originator
When the recipient has requested the Redirection of Incoming Messages EoS, this MT
element of service enables an originating UA to instruct the MTS that redirection should not be applied to
this particular submitted message. Support for this service is mandatory because it could impact the
security of a given message. This service shall be supported as a user option. (See X.400 B.68)
ai. Redirection of incoming messages
This MT element of service enables a UA to instruct the MTS to redirect incoming

messages addressed to it, to another UA or to an AL, for a specified period of time, or until revoked.
Redirection takes place before delivery to the intended recipient. It is therefore distinct from the Auto-
forwarded Indication element of service, where auto-forwarding takes place after delivery. When
security provisions are in force, the MTS may examine security labels in order to determine whether
redirection will take place, and to determine different alternate recipients for different incoming
messages. Redirection based on other criteria in the message envelope, such as the priority field, may
also be required by national or local policy. Use of this service may be impacted by security policy. The
Directory service may be used to provide support for this service by allowing originators to include
necessary keying information in case the message is redirected. The presence of this service is required
in any implementation, but the way in which redirection is used shall be determined by security or local
policy. (See X.400 B.69)

202. (continued)
aj. Reply request indication
This MM element of service allows the originator to request, on a per-recipient basis, that a
recipient send a message in reply to the message that carries the request. The originator can also
optionally specify the date by which any reply should be sent and the names of one or more users and
ALs who the originator requests be among the preferred recipients of any reply. MMHS uses this service
for the purpose of military acknowledgment. Where acknowledgment is defined as "a communication
indicating that the message to which it refers has been received and the purpose understood by the
addressee." Acknowledgment should not be confused with reply, but a prompt reply may save a
subsequent request for acknowledgment. In addition, Reply Request service should not be confused
with Delivery Notification and Receipt Notification EoS. The Delivery Notification and Receipt
Notification EoS are used for reporting message transmittal steps and to convey proof that the recipient
has understood the message. When a Reply Request Indication is received, the corresponding Reply
message indicates whether the original message has been both received and understood. This service
shall be supported as a user option. When this indication is present, it shall be prominently displayed to
the user. Additionally, if the supporting protocol elements reply-time and reply-recipients are present,
they shall also be displayed. Note that Blind Copy Recipients should consider careful to whom a reply is
sent to, so that the meaning of the Blind Copy Recipient Indication EoS is preserved. (See X.400 B.72,
Annex A B.72)
ak. Replying MM indication
This MM element of service allows the originator of a message to indicate to the recipients
that the message is being sent in reply to another message. The recipients of the reply receive it as a
regular message, together with an indication of the message to which it is a reply. This service shall be
supported as a user option. The use of this indication is encouraged when a reply was requested. When
this indication is present, it shall be displayed to the user. (See X.400 B.73)
al. Requested preferred delivery method
This MT element of service allows a user to request, on a per-recipient basis, the

preference of method or methods of delivery. Non-delivery results when preference(s) cannot be
satisfied. No requirement has been identified for this service. Its support is optional. (See X.400 B.76)
am. Subject indication
This MM element of service allows the originator to indicate to the recipient(s) a user
specified short description of the message. This is different from the standardized codes to be carried in
the Subject Indicator Code extension service. This service shall be supported and shall be displayed to
the user. The subject field will always be used, but it should be kept short, concise and readable. (See
X.400 B.88, Annex A B.88)
an. Use of distribution list
This MT element of service enables an originating UA to specify, on a per-recipient basis, a

Distribution List (DL) in place of all the individual recipients (users or nested DLs) mentioned therein.
The MTS will add the members of the list to the recipients of the message and send it to those members.
Support for this service shall be optional. Determination of where in the MMHS the DL expansion takes
place may be the subject of national policy based on security requirements. National policy may also
dictate support of the military extension Use of Address List EoS instead of DLs, and the relationship with
the Exempted Addresses EoS. (See X.400 B.92)

203. Optional Elements of Service not used in MMHS
The following services are available because of the baselined X.400 EoS; however, they are not
required for ACP 123 use. These EoS and protocol elements may, however, be used to support
nationally specific messaging characteristics within a host nation. These EoS shall not be conveyed
internationally except by bilateral agreement. If the protocol elements to support these services are
present in international messages they can be ignored. These EoS should not be prompted for or
displayed at the user interface, except where it is necessary to support specifically required national or
local messaging features. They are included in the P772 content definition in order to retain
harmonization with STANAG 4406.
a. Implicit conversion
This MT element of service enables a recipient UA to have the MTS perform necessary
conversion(s) on a message prior to delivery. Conversion refers to converting the EIT of one or more
body parts of the message to another EIT. Conversion in X.400 is performed by the MTS. This service
is not explicitly requested on a message by either the originator or the recipient. If security services are
used such that the message is carried encrypted, the MTS is not likely to have the information necessary
to perform implicit conversion. (See X.400 B.34)
b. Importance indication
This MM element of service allows the originator to indicate to the recipient an assessment
of the relative importance of the message being sent. Three levels of importance are defined: LOW,
NORMAL, and HIGH. This field is used to carry originator to recipient information only. The military
extensions of Primary Precedence and Copy Precedence will be used to convey at least six different
levels of importance for Action versus Information recipients, thus providing more information than this
service. Therefore this service is redundant and its use might cause confusion to recipients. The
importance field shall not be originated by or displayed to the user. (See X.400 B.35)
c. Probe
This MT element of service enables a UA to establish, before submission, whether a

particular message could be delivered. This service includes the capability of checking whether the
content size, content type, or EITs would render the message undeliverable. For ALs, the probe merely
indicates whether the originator has the right to submit messages to the AL. The invocation of this
service from an MM-UA is prohibited due to security considerations. Interface points to the MMHS shall
refuse the ProbeTransfer operation. If one is detected it shall be logged and ignored. A Non-Delivery
Notification shall not be returned to the originator. (See X.400 B.63)
d. Restricted delivery
This MT element of service enables a recipient UA to indicate to the MTS that it is not
prepared to accept delivery of messages from certain originating UAs or DLs. No requirement has been
identified for this service. Additionally, no protocol to support this service has been defined in X.400.
(See X.400 B.77)
e. Return of content
This MT element of service enables an originating UA to request that the content of a

submitted message be returned with any non-delivery notification. This service shall not be used as it
could impact performance on the network. It is the originator's responsibility to retain a copy of a
message for a required period of time or until assurance of delivery. Delivery Notifications can be
matched with the original message, by the Message Identification. Therefore there is no requirement to
support the Return of Content element of service. (See X.400 B.78)

203. (continued)
f. Sensitivity indication
This MM element of service allows the originator of a message to specify guidelines for the
relative sensitivity of the message upon its receipt. This service is used to carry information from
originator to recipient only. The standards do not address the actions or events to be taken based on the
different values that can be carried by this service. The use of this service may conflict with the
Message Security Label, which conveys more information. The sensitivity indication shall be
disregarded by the MM-UA. The sensitivity field shall not be originated by or displayed to the user. (See
X.400 B.80, Annex A B.80)
204. Physical Delivery Elements of Service
The Physical Delivery EoS are used when interfacing to a Physical Delivery Service (PDS) such
as a national postal service. All ACP 123 users will be served by MM-UAs. If a message is printed for
local distribution, this will occur after message delivery has occurred. There may be a requirement for
some nations to support a commercial refile capability and therefore the support of a Physical Delivery
Access Unit (PDAU). Therefore, the EoS to support interworking with a PDS are optional in ACP 123.
Support for origination of the addressing attributes to indicate Physical Delivery recipients of messages is
also optional.
205. Security Elements of Service
Support of the security EoS defined by the X.400 Civil standards is optional. The security
services required within the ACP 123 environment are identified in section 4.II.
206. Message Store Elements of Service
The MS EoS are associated with the optional use of an X.400 MS. Support for the MS EoS are
dependent on use of an MS and do not impact interoperability with configurations without an MS.
Support of the MS access protocol (i.e., P7) across international boundaries is not required by ACP 123.
This is due to the technical difficulty associated with de-coupling the MS design from that of the user
interface of the UA. Further discussion of the use of MSs will be found in 3.II.305 and 3.III.
a. MS register
This element of service allows a user of an MS to register various information with it in

order to modify aspects of its behavior. Information that can be registered includes the performance of
automatic actions, the default set of information retrieved by the Stored Message Fetching and Stored
Message Listing EoS, and the credentials used by the MS to authenticate the MS-user (i.e., the UA). If
an MS is available this service is mandatory. (See X.400 B.95)
b. Stored message alert
This element of service allows a user of an MS to register relevant sets of criteria that can
cause an alert to be generated to the user when a message arrives at the MS satisfying the selected
criteria. Criteria can be any attributes available to the MS. These could include the priority field,
originator field, etc. The alert will take place if the user is connected and on-line with the MS when the
message triggering an alert arrives, or the MS can use alternative means to inform the user. If a
recipient who may receive time critical messages has a MS, then the associated MS shall support this
service. (See X.400 B.82)

206. (continued)
c. Stored message auto-forward
This element of service allows a user of the MS to register requests that the MS auto-
forward selected messages that are delivered to it. Criteria for selection can be chosen from the
attributes available in the MS. One text per selection criteria can also be specified to be included with
each auto-forwarded message. Support for this service may be impacted by security policy. However if
a recipient who may be unavailable for periods of time has a MS, then support for this service shall be
available. (See X.400 B.83)
d. Stored message deletion
This element of service enables a recipient UA to delete certain of its messages from the
MS. Messages that have not been listed can not be deleted. If an MS is provided, then this service is
mandatory. (See X.400 B.84)
e. Stored message fetching
This element of service enables a recipient UA to fetch a message or portion of a message

from the MS. Messages, or message portions, can be fetched based on the same criteria that can be
used for listing stored messages. If an MS is provided, then this service is mandatory. (See X.400 B.85)
f. Stored message listing
This element of service provides a recipient UA with a list of information about certain of its
messages stored in the MS. The information comprises selected attributes from a message's envelope
and content and others added by the MS. If an MS is provided, then this service is mandatory. (See
X.400 B.86)
g. Stored message summary
This element of service provides a recipient UA with a count of the number of messages
satisfying specified criteria based on one or more attributes of the message stored in the MS. If an MS is
provided, then this service is mandatory. (See X.400 B.87)
SECTION II
ADDITIONAL MILITARY ELEMENTS OF SERVICE
a. The additional Military EoS provide services required within the MMHS context that are not
found in the civilian X.400. ASN.1 for the new protocol elements that will support these services is
defined in Annex A.
207. Military Elements of Service
Support for the following Military EoS is mandatory. If these services are present in a message,
the information contained shall be displayed to the user.
a. Primary Precedence
This element of service enables an originating MM-UA to convey the military precedence
level of a message in the MM content type's heading for a Primary recipient. This service is provided not
only as information from originator to recipient, but also is used to automatically select the MTS Grade of

207.a (continued)
Delivery. This service is supported by the military heading extension primary-precedence. (See page A-
30) The six defined levels of precedence (see 4.I.403.a for semantic definitions) are mapped to only
three levels of Grade of Delivery. Military precedence is mapped to the MTS priority protocol element as
follows:
Military Precedence MTS Priority
DEFERRED (0) NON-URGENT
ROUTINE (1) NON-URGENT
PRIORITY (2) NORMAL
IMMEDIATE (3) NORMAL
FLASH (4) URGENT
OVERRIDE (5) URGENT
The delivery time requirements will be assigned in such a way as to meet or exceed current
requirements for the transfer of messages at each military precedence level. The actual precedence
assigned for Primary and Copy recipients will be conveyed from originator to recipient and shall be
displayed to the recipient. (See Annex A B.101) The Primary Precedence level shall be prominently
displayed for each Primary recipient user. Values 16 through 31 are reserved for national use. National
policy will mandate these values and the mapping to the Grade of Delivery.
b. Copy Precedence
This element of service enables an originating MM-UA to convey the additional precedence
of a message in the MM content type's heading for a Copy recipient. The Copy Precedence has the
same range of values as the Primary Precedence. The value of the Copy Precedence assigned shall be
the same or a lower value than the Primary Precedence of the same message. This service is provided
for conveying information from originator to recipient only. This service is a user option, however if there
are Copy Recipients in a message, Copy Precedence will be selected if it is different from the Primary
Precedence. If present, the Copy Precedence shall be displayed to the user. (See Annex A B.102) This
service is supported by the military heading extension copy-precedence. (See page A-30) The Copy
Precedence level shall be prominently displayed for each Copy recipient user.
c. Message Type
This element of service enables originating MM-UAs to distinguish messages that relate to a
specific exercise, operation, drill, or project. (See Annex A B.103) The information carried in support of
this EoS is an integer identifying the type of the message and an optional printable string specifying the
name of exercise, operation, project or drill. This service is carried by the military heading extension
message-type. This service is a user option. If present, the Message Type shall be prominently
displayed to the user. (See page A-30)
(1) The value exercise (0) shall be assigned to all formally released military messages
sent for training exercises, command post exercises, tactical exercises and maneuvers conducted in the
interest of training and readiness. A printable string, assigned by a proper authority, shall be included in
the identifier field to distinguish a specific exercise scenario, or to convey any additional information that
is specific to the exercise. The organization conducting the exercise shall include the appropriate
instructions for identifying exercise messages in the directive for the conduct of the exercise in order to
preclude alarming non-participants.

207. (continued)
(2) The value operation (1) may be assigned to formally released military messages
pertaining to a specific military operation. An "operation" is a coordinated action by one or more of the
Services that generally involves mobilization of armed forces. If the Message Type value is used, a
printable string identifier shall in the identifier field to distinguish the specific operation in question, and
convey any additional information that is specific to the operation.
(3) The value project (2) may be assigned to formally released military messages
pertaining to a specific support activity project. A “project” is a logistic, programmatic, or acquisition
activity that generally does not involve mobilization of armed forces. If this Message Type value is used,
a printable string identifier shall be included in the identifier field to distinguish the specific project in
question, and convey any additional information that is specific to the project.
(4) The value drill (3) shall be assigned to all formally released military messages
pertaining to a specific military drill. A printable string identifier may be included in the identifier field to
distinguish the specific drill in question, and convey any additional information that is specific to the drill.
(5) Values in the range of 128 to 255 are not defined and may be used as defined by
national policy or as agreed bilaterally.
d. Exempted addresses
This element of service is used to convey the names of members of an AL that the
originator has specified are to be excluded from receiving the message. An AL could be carried either
by the address-list-indicator heading field, as an X.400 DL, or as a list name on the primary-recipients or
copy-recipients field. Exclusion is provided at the point of AL expansion (see clause 4.III.437.a). The
names or addresses of exempted list members is also conveyed to the remaining recipients and shall be
displayed to the user. There is no guarantee that the exempted addresses will not receive the message
as the result of redirection, DL expansion, etc. (See Annex A B.105) This service is carried by the
military heading extension exempted-address. (See page A-29)
e. Extended authorization info
This element of service enables the originating MM-UA to indicate to a recipient MM-UA the date
and time when the message was released as a Date-Time Group (DTG). Depending upon national
requirements, the DTG may indicate either the date and time when the message was officially released
by the releasing officer or the date and time when the message was submitted to the communications
facility for transmission. (See Annex A B.106) The information for this service is carried in the military
heading extension extended-authorisation-info. This information shall be automatically added to all
officially released messages as a default; however, the originator shall have ability to override the
information in this extension. If this information is present upon reception, it shall be displayed to the
user. (See page A-41)
f. Distribution code
This element of service enables the originating MM-UA to give distribution information to a
recipient MM-UA. The recipient MM-UA can use this information to perform distribution of the message
to one or more persons or staff cells. This service contains two components, the Subject Indicator Code
(SIC) and a Distribution Code, each of which is optional. The Distribution Code allows for future
definitions of distribution criteria for either national or Allied use. Any number of codes may be specified.
The assignment of the Distribution Code can be privately defined or may be subject to future
standardization. SICs are published, nested codes that provide information for message distribution after
delivery to the recipient organization. For example the NATO Subject Indicator System (NASIS), defined

207.f (continued)
in APP-3, is one source for SICs. (See Annex A B.107) The information for this service is carried in the
military heading extension distribution-codes. This information is a user option on origination, but shall
be displayed to the user if present on reception. (See page A-29)
g. Message Instructions
This element of service enables the originating MM-UA to indicate to the recipient MM-UAs
that message instructions accompany the message. (Message instructions are also called remarks.) It
may be used to carry Operating Signals specified in ACP 131 and related national publications.
Message Instructions are not visible within the MTS and therefore can not be acted by the MMHS. They
are used for informational purposes at the end points. This information, if present, shall be displayed to
the user. (See Annex A B.109) This service is a user option. The information for this service is carried
in the military heading extension message-instructions. (See page A-29)
(1) For each message sent, the originator shall determine if any of the message recipients
have been placed under Minimize conditions. The originating user shall be prompted to consider
omitting any recipient for which Minimize is indicated. If the user chooses to include such a recipient
despite the Minimize condition, then “MINIMIZE CONSIDERED” shall be included in the Message
Instructions EoS. If this instruction is present, then the message should be delivered to recipient MM-
UAs that are under Minimize restrictions. If this instruction is absent, then system components that have
access to the MM heading fields may block the message depending upon local policy. Note that specific
requirements for specific component handling of Minimize is beyond the scope of this document. (See
4.I.409)
(2) For each message, the originator shall have the option to request the extent of
distribution be limited after the messages are received by the intended recipients (primary and copy
recipients and other recipients indicated). If the originator decides the message should be limited to
those who need to know, then “LIMITED DISTRIBUTION” shall be included in the Message Instruction
EoS. If this instruction is present, the recipients shall respect the originator’s request and distribute the
message only to those whom the recipient determines require access to the message. The meaning
implied by the message instruction, “LIMITED DISTRIBUTION,” shall be defined by local policy. If this
instruction is present, it shall be prominently displayed to the user.
(3) After the originator has determined the recipients of the message, the originator shall
then have the option to instruct the recipients not to further distribute the message without the originator’s
approval. If the originator determines the message should not be distributed beyond the specified
recipients (primary and copy recipients and other recipients indicated), then “NO DISTRIBUTION” shall
be included in the Message Instruction EoS. If this instruction is present, the recipients shall not distribute
the message further without first gaining approval from the message originator. The definition of further
distribution shall be determined by local policy. If this instruction is present, it shall be prominently
displayed to the user.
(4) For each message to be received by the intended recipients, all recipients must have
access to the MMHS. If the originator knows that the intended recipient is temporarily without MMHS
access, then the recipient’s name, responsible for getting the message to the intended recipient, shall be
placed before “SEND TO” followed by the intended recipient’s name. The recipient’s name, “SEND TO”,
and the intended recipient’s name shall be included in the Message Instruction EoS. The originator shall
ensure that the intended recipient’s name is unambiguously specified. If this instruction is present, the
recipient of the message shall deliver the message to the recipient specified after the “SEND TO” in the
Message Instruction. The method of delivery and extent to which this Message Instruction will be used
shall be determined by national policy. If this instruction is present, it shall be prominently displayed to
the user.

207.g (continued)
(5) Any message for which a signal (See 4.I.403.b) is required at the recipient MM-UA, but
which does not qualify for a high precedence value (i.e., OVERRIDE, FLASH, and nationally defined
values) shall have the instruction “ALARM REQUIRED” included in the Message Instructions EoS. Any
received message containing this instruction shall be handled as a high-precedence message by the
MM-UA in accordance with clause 3.I.304. Procedures for determining what messages may use this
Message Instruction will be determined by national policy.
(6) The originator shall have the option to request the message not be sent via fleet
broadcast. If the originator determines that the message should not be sent via fleet broadcast, then
"NO FLT BRDCAST" shall be included in the Message Instruction EoS. If this instruction is present,
Fleet Broadcast stations shall not transmit the message via fleet broadcast. If this instruction is present,
it shall be prominently displayed to the user.
(7) The originator shall have the option to request the message not be sent via over fleet
operational intelligence broadcast. It is the originator’s responsibility for determining if this instruction
applies to the message. If the originator determines that the message should not be sent via fleet
operational intelligence broadcast, then “NO FLT OPINTEL BRDCAST” shall be included in the Message
Instruction EoS. If this instruction is present, fleet broadcast stations shall not send the message via
fleet operational intelligence broadcast. If this instruction is present, it shall be prominently displayed to
the user.
(8) The originator shall have the option to request a Night Action which indicates that the
alternate recipients shall recall intended recipients to receive a message. Any originator that uses this
message instruction shall assure that an originator requested alternate recipient (see clause 2.I.202.ad)
is specified for each intended recipient of this message. If the originator determines that the message
requires a Night Action, then "NIGHT ACTION" shall be included in the Message Instruction EoS. If this
instruction is present, an alternate recipient shall notify (via telephone, pager, etc.) the intended recipient
that a Night Action message was received, and the alternate recipient shall then forward the message to
the originally intended recipient. It is not required that the copy recipients be notified. If this instruction is
present, it shall be prominently displayed to the user.
h. Clear service
This element of service indicates to the recipient MM-UA that the message containing
classified information has been transmitted over an unsecure channel. The message, when received,
shall be marked with the phrase "RECEIVED IN CLEAR, TREAT AS CONFIDENTIAL" by the MM-UA
prior to presentation to the end user. This phrase will be prominently displayed to the user. This may be
used to indicate that the message originated outside the MMHS (e.g., in a tactical environment). (See
Annex A B.112) This service is provided by interpretation of the values of the message security label.
The value "CLEAR" in the privacy-mark field, in conjunction with an appropriate military value in the
security-policy-identifier field, is used to represent the clear service. The clear service is defined to be
messages of any classification except TOP SECRET which in tactical operations, simulated or actual,
the speed of delivery is so essential that time cannot be spared for encryption and the transmitted
information cannot be acted upon by the enemy in time to influence current operations. In such cases,
transmission in the clear must be authorized separately for each message. These messages shall be
handled as CONFIDENTIAL material. Should the addressee desire the information to be forwarded to
another addressee, a new message shall be originated, appropriately classified, and handled as the
situation dictates. These rules do not apply to messages that are not normally encrypted such as enemy
contact reports, position reports, etc. The security policy identifier to be used in conjunction with the
"CLEAR" privacy-mark may be specified by national policy or international agreement. The ability to
originate message security label indicating the clear service may not be available to all MM-UAs.

207. (continued)
i. Other recipient indicator
This element of service enables the originator to indicate to the recipient the names of one
or more recipients, as well as the category (Primary or Copy) in which they are placed, that are intended
to receive, or have received, the message via other means. The intent of this service is to enable a
recipient to determine which recipients are intended to receive the message without the use of MMHS,
as well as the category in which they are placed. While the Primary and Copy Recipient Indication EoS
and address-list-indicator field provide the names of recipients that can be reached through MMHS, other
recipients can be determined with this service element. This service is a user option. The information
for this service is carried in the military heading extension other-recipient-indicator and if present, shall
be displayed to the user. (See page A-30) (See Annex A B.113)
This element of service does not carry the reason why the other recipient(s) will not receive the message
through MMHS. Some reasons might include:
(1) the recipient is not a user of the MMHS and has been sent the message by other
means;
(2) the originator knows (or presumes) that a secure path to the recipient will not be found
through the MMHS and has therefore sent the message by other means; and
(3) the recipient has already received the message by other means before it was entered
in the MMHS.
j. Originator reference
This element of service enables the originating MM-UA to indicate to a recipient MM-UA a
reference called the "originator's number". The originator's number is used by the originating
organizational unit. The use of this field will be further clarified by national policy. This service is
different from the IPMIdentifier in that this reference is assigned by the originator, while the IPMIdentifier
is supplied by the MM-UA. (See Annex A B.111) This service is a user option. This service is carried in
the military heading extension originator-reference. (See page A-30)
k. Use of Address List
This element of service conveys the name of a pre-defined list of recipients to which the
originator has sent the message. The AL can be qualified as either a Primary or Copy recipient, and
indicates if notifications or replies are requested from the members. The Exempted Addresses element
of service can be used in conjunction with an AL to exclude certain members of the list. Originating
domains are responsible for expanding ALs for which they have configuration responsibility. This service
is carried either as an ORName of an AL in the primary-recipients or copy-recipients protocol elements or
in the military heading extension address-list-indicator. (See page A-30) Use of the address-list-
indicator field to support this is for transition only. If the AL is addressed as a copy recipient, all
members of the list shall be considered copy recipients. If the AL is addressed as a primary recipient,
individual members may be either primary or copy recipients and should know their role by basis of
membership in the list. When the address-list-indicator is used to convey the AL, the status of the AL as
a primary or copy recipient is indicated by the state of the primaryAddressList and copyAddressList
elements. If an AL is present, it shall be displayed to the user.

208. Transition Elements of Service
The following Military EoS are required for interworking with older military messaging domains
(ACP 127). They are included in ACP 123 in order to allow ACP 123 users to correctly receive and
understand these elements from ACP 127 gateways. This will enable the ACP 123 environment to
interoperate with ACP 127 in the short term, and to do so in a harmonized way. Origination of these EoS
is not a requirement for UAs in the ACP 123 environment because any gateways should operate
transparently, without the need for originating users to be aware of the environment of the recipients.
Once all nations have fully deployed the ACP 123 MMHS, support of these services will no longer be
required.
a. Handling instructions
This element of service enables the originator to indicate to the recipient that local handling
instructions accompany the message, and that the message requires manual handling by a traffic
operator. (Handling instructions are also called transmission instructions.) (See Annex A B.108) This
service carries information that is only used by the traffic operators in ACP 127. It is not necessary in the
ACP 123 network. This service is for transition only. If this service is deemed necessary for a message
originated by a user in the older (ACP 127) messaging domain, the information for it will be carried in the
military heading extension handling-instructions. (See page A-29)
b. Pilot forwarded
This element of service is intended for use with gateways from older military messaging
domains (ACP 127) and allows a gateway to translate a pilot message. The original received "body/text"
of the message is sent as the "text body" of a new message. The Pilot Forwarded service conveys
information that equals or supersedes the received heading information for precedence, classification,
local handling instructions and addressing. (See Annex A B.115) This service is for transition only. If
the information for this service is received coming into the MMHS, it is carried in the military heading
extension pilot-forwarding-info. (See page A-31) This information, if present, shall be displayed to the
user.
c. Corrections
This element of service enables a message originating in an older military messaging

domain (ACP 127) to indicate to the recipient that there are corrections required to the text body. (See
Annex A B.114) This service is for transition only. During the transition if corrections are present in an
ACP 127 message that must be translated into an ACP 123 message, the corrections will be carried in
the externally defined body part type corrections-body-part. If this information is present in a received
message, the user shall have the capability to display it. (See page A-32)
d. ACP127 Message Identifier
This element of service conveys the message identifier of an ACP 127 formatted message
in MMHS. This identifier consists of the RI of the originating COMCEN, the Station Serial Number, and
the Filing Time. (See Annex A B.116) This service is for transition only and will be used to support the
tandeming of full ACP 127 messages through MMHS domains. It may, however, be used by MMHS
domains who wish to ensure a unique message identifier that is common to both MMHS and ACP 127 for
messages originated by ACP 127 users. It will be carried in the acp127-message-identifier heading field.
If this information is present, the user shall be able to display it. (See page A-31)
e. Originator PLAD
This element of service enables the originator to indicate to a recipient the plain language
address of the originator of the message. (See Annex A B.117) This service is for transition only. It is

208.e (continued)
only necessary if there is no easy way of translating between the originator's PLAD and an ORName.
The information for this service, together with the Extended Authorization Info service, provides a cross
reference for message identification in both ACP 127 and MMHS domains. It is carried in the military
heading extension originator-plad. (See page A-31)
f. Codress message indicator
This element of service enables the originator to indicate to the recipient that the message
is in codress format. This applies only to codress encrypted messages, which are restricted to a single
body part. Codress is defined as a procedure in which the entire address of a message is encrypted
within the text, while the heading of any transmission of that message contains only information
necessary to enable communications personnel to handle it properly. Codress may be implemented by a
nation, service or appropriate Allied authority for use with high grade off-line cryptographic systems.
This service is for transition only, and is carried in the codress-message heading extension. This service
is supported on reception to enable codress messages from older military messaging domains (ACP 127)
to be carried inside an ACP 123 message. (See Annex A B.110) The information for this service is
carried in the military heading extension codress-message. (See page A-30) A value of zero (0)
indicates "NC" or No Count.
g. ACP 127 Notification Request
This service element enables the originator to request notifications specifically from ACP
127 gateways. (See Annex A B.118) In cases where interoperability with ACP 127 domains is provided
transparently, this service may not be practical. This is because users will not necessarily know in
advance whether a recipient address is located within an ACP 127 domain. ACP 127 Notifications can be
requested for the following scenarios:
(1) Positive notification – the ACP 127 gateway successfully transfers the message and
accepts responsibility for its submission into the ACP 127 domain;
(2) Negative notification – the ACP 127 gateway has received the message, but fails to
transfer it; and
(3) Transfer notification – the ACP 127 gateway successfully transfers the message but
has not kept a record of the message and does not accept responsibility for it.
Depending upon national policy, the gateway scenario described by the Transfer Notification may be
prohibited. This service is for transition only, and is carried in the acp127-notification-request extension
of the RecipientSpecifier. (See page A-31)
h. ACP 127 Notification Response
This element of service conveys the results of an attempt to transfer a message into an
ACP 127 domain. (See Annex A B.119) It indicates whether the transfer was positive, negative, or
positive but without responsibility. It also conveys the receipt time, the ALs of the message, the ACP
127 recipient address, and any pertinent supplementary information. This service is for transition only,
and is carried in the acp127-notification-response extension of the MN element other-notification-type-
fields. (See page A-31) If this information is present, the user shall be able to display it.

(Reverse Blank)
CHAPTER 3
MESSAGE HANDLING SYSTEM COMPONENTS
SECTION I
Message Transfer System
a. In the X.400 Message Handling Environment (MHE), messages are relayed in a

store-and-forward fashion between MTAs until the message reaches the specified destination(s). The
collection of MTAs (and the underlying communication service) is referred to as the MTS. Since it has
been agreed that there may be a requirement to use a commercially provided MTS service,
modifications to the existing MTS Transfer Protocol (i.e., P1) used by the MTAs to exchange messages
have been avoided. Modifications to the submission and delivery protocols (i.e., P3 and possibly P7)
used in communicating to the MTAs have also been avoided in order to enable the use of commercial
MTAs.
b. To ensure interoperability and further maximize the possible use of commercial MTAs, ACP
123 defines specific profiles for use of MHS protocols. These profiles are addressed in Chapter 5.
c. Additionally, the following services provided within the MTS may be exploited to meet
specific military messaging requirements:
301. Prohibition of Probes
(See 2.II.203.c) Submission control will be used to prohibit a probe from being originated within
the MMHS environment. However, it shall be the responsibility of MMHS interface points to prohibit
probes that originate outside the MMHS environment from entering an MMHS domain. MTAs shall
refuse the ProbeTransfer operation. Reports concerning a probe shall not be returned to the originator of
the probe. If a probe is received at an MTA, this shall be logged as a potential security problem. The log
shall include the probe's originator, the originating domain, the time of receipt, and the intended
recipient. (See 4.I.410)
302. Delivery and Non-Delivery Reports
(See 2.II.201.g, 2.II.202.l and 4.I.405) Since the originator is responsible for messages until they
have been delivered, Delivery and Non Delivery Reports can be utilized to indicate when a shift of
responsibility has occurred. Policy or local implementation can dictate whether Delivery Reports are
provided to the user or used to automate retention of messages at the originating system for the required
time as a default. Delivery Reports can always be requested by the originating user. An MTA in the
MTS shall generate a Non-Delivery Report if it has held messages with a priority field of URGENT,
NORMAL, and NON-URGENT for 12 minutes, 60 minutes, and 96 hours, respectively (see 4.I.403).
These limits are imposed in cases where an MTA encounters transient problems for which a retry may
succeed, and for which the Latest Delivery Designation EoS was not specified by the originator. The
time limit for NON-URGENT was determined by considering the likely duration of periods of unmanned
operation including 3 day weekends and time zone differences.

303. Retention of Other Recipients
The MTA shall not discard the transfer envelope per-recipient fields of recipients for which the
responsibility flag has been set (i.e., for which delivery has already occurred). This Retention of Other
Recipients is necessary to ensure that the Disclosure Of Other Recipients EoS functions correctly.
304. Configuration Management
Each time a new MTA is introduced in to the network there are ramifications for other MTAs.
Routing decision tables need to be updated to reflect the new MTA and the UAs for which it will be
responsible for delivering messages. MTA peer-to-peer authentication information must be distributed to
every MTA to which an MTA can make a direct association. Network information such as address and
available communications stack must be registered and made available. Registration of appropriate
names and addresses will be performed according to established national registration procedures.
Configuration management information for the messaging and its supporting security services must be
securely controlled to prevent unauthorized modification.
305. Audit Trail and Logging Requirements
Storage of audit data by the MTA is required to support security monitoring, accountability, and
tracability of messages to the source. This information will be used to provide accountability and support
for any required tracer actions. All stored audit data shall be maintained for at least ten (10) days. Data
will be recorded and stored at each MTA to provide an audit capability for messages that are sent an
received. The following table indicates which audit information is required at a minimum to be logged by
the MTA for inbound and outbound messages. National policy may require longer retention periods and
additional information be stored. The integrity of audit logs must be protected.
MTA Logging Requirements

Inbound Messages Outbound Messages
Message Submission Envelope: Message Delivery Envelope:
MTS Message Identifier MTS Message Identifier
Message Submission Time Message Delivery Time
Priority Priority
Message Transfer Envelope: Message Transfer Envelope:
MTS Message Identifier* MTS Message Identifier*
Priority* Priority*
Bind Arguments & Results* Bind Arguments & Results*
Probe Submission Envelope† Report Delivery Envelope
Probe Transfer Envelope*† Report Delivery Time
Report Delivery Envelope: Report Transfer Envelope*
Report Delivery Time Time of Transfer Out*
Report Transfer Envelope*
Time of Transfer In*
* MTAs operating in a relay capacity are responsible for logging the marked attributes.
† If a probe is received at an MTA, this should be logged as a potential security

problem, including the originator, the originating domain, as well as the time of receipt
and the intended recipient.

SECTION II
Military Messaging User Agents (MM-UA)
a. Enhancements to commercial X.400 services to support Military Messaging occur mainly in

the definition of a new message content type. This content type will be supported by enhanced UAs for
military messaging. The services supported by this content type are described in the previous chapter.
The protocol that supports the services is described using ASN.1 in Annex A. These UAs are referred to
as MM-UAs. Issues to be addressed in national supplements to complete the definition of MM-UAs
include:
– Release authorization procedures and techniques,

– Verification of message authenticity,
– Message accountability,
– Distribution policies,
– Requirements (prohibitions) for the use of MSs or intermediate storage between the MTA
and a remote UA.
306. Storage and retrieval policies
How long messages shall be stored and how they can be accessed after receipt will be defined
by national policy. At a minimum all MM-UAs will store both outbound and incoming messages for a
minimum of 10 days. This is to support the possible request for retransmission of a message and in
support of message accountability and tracer action. Outgoing messages shall be stored with the original
security services invoked since any retransmission requires the precise form forwarding of the original
message. If the message was originally encrypted, it must be decrypted by the originator prior to
retransmission.
The Probe EoS presents a serious security risk in the MMHS environment. MM-UAs are
therefore prohibited from originating probes in accordance with clause 2.I.203.c.
308. Precedence Based Display
The user interface of the MM-UA shall prominently indicate the presence of unread high
precedence (i.e., precedence that map to the URGENT Grade of Delivery) messages. The MM-UA
should automatically adjust the user's display to reveal and highlight unread high-precedence messages
in preference to either low precedence messages or previously read high-precedence messages.
309. Precedence Signaling
Messages that map to the URGENT Grade of Delivery shall cause the MM-UA to prominently
(e.g., audibly) signal the recipient upon delivery.
310. MMS Auto-Actions
a. Auto-discard
The MM-UA shall not automatically discard messages that have either the expiry-time or
obsoleted-IPMs heading fields present. Messages shall only be deleted by the intended recipient and in
accordance with national audit trail requirements.

310. (continued)
b. Auto-forward
The MM-UA may be configurable to autoforward messages. If configurable to forward

messages then the MM-UA may auto-forward received messages to one or more recipients.
c. Auto-acknowledgment
The MM-UA shall not be configurable to automatically originate receipt notifications for
messages with a notification-request field on behalf of the user.
Storage of audit data by the MM-UA is required to support security monitoring, accountability,
and tracability of messages to the source. This information will be used to provide accountability and
support for any required tracer actions. All stored audit data shall be maintained for at least ten (10)
days. Data will be recorded and stored at each MM-UA to provide an audit capability for messages that
are submitted and received. The following table indicates which audit information is required at a
minimum to be logged by the MM-UA for submitted and received messages. National policy may require
longer retention periods and additional information be stored. The integrity of audit logs must be
protected.
MM-UA Logging Requirements

Submitted Messages Delivered/Receive Messages
Message Content: Message Content:
Authorizing Users Extended Authorization Information
(Release Authority) MM Identifier
Extended Authorization Information Originator Indication
MM Identifier Precedences Assigned
Notifications Requested CSP Security Label
Precedences Assigned Message Delivery Envelope:
Requested Recipients MTS Message Identifier
CSP Notifications Requested Message Delivery Time
CSP Security Label Bind Arguments & Results
Message Type Report Delivery Envelope:
Message Submission Envelope: Report Delivery Time
Deferred Delivery Time Time of Retrieval from MS
(if applicable) (if MS is implemented)
MTS Message Identifier
Time of Submission
Bind Arguments & Results

SECTION III
Message Stores
a. An MS is designed to support delivery of messages when the intended recipient's UA is

unavailable to accept messages from the MTS. The MS is an optional component and its use with any
given MM-UA will be determined by national or local policy. Support of the MS access protocol (i.e., P7)
across international boundaries is not required by ACP 123. This is due to the technical difficulty
associated with de-coupling the MS design from that of the user interface of the UA. However, when an
MS is used, it must not degrade the service provided. This section is devoted to describing the issues
surrounding the use of an MS in a military environment.
b. To support retrieval of MMs from a MS based on MM heading fields, MS attributes were

defined (see Annex A). MSs that support retrieval of messages based on MM-specific MS attributes are
referred to as MM-MSs.
312. MS Functional Restrictions
a. Auto-deletion
Automatic deletion of messages by the MS is strictly prohibited. Messages shall only be

deleted from the MS by the intended recipient and in accordance with the national audit trail
requirements policy.
b. Auto-forward
If an MM-UA and its associated MS may be unmanned, then in order to handle receipt of high
precedence messages, the MS shall support automatic forwarding. Automatic forwarding based on the mt-
message-submission-time and mt-priority attributes shall be provided. Any URGENT message shall be
auto-forwarded if the time elapsed from submission exceeds ten (10) minutes. Any NORMAL message
shall be forwarded if the time elapsed from submission exceeds forty five (45) minutes. National or other
policy may specify shorter times for automatic forwarding. When automatic forwarding is performed by
the MS, then a content type of P772 shall be originated with the delivered message included as either a
forwarded-CSP-Message-Body-Part (for messages received with CSP protection) or an mm-message-
body-part (for messages previously forwarded without CSP protection).
c. Auto-alert
Automatic alerts shall be sent to recipient’s MM-UA immediately on delivery of URGENT

and NORMAL priority messages. In cases where the MM-UA is not available to service the alert (i.e., no P7
association established), mechanisms must be supported that allow the user to be alerted. These mechanisms
may include support of messaging protocols (e.g., special message sent to an alternate position indicating that
alerts are not being serviced) or other non-messaging solutions (e.g., proprietary interface to a paging service).

Storage of audit data by the MS is required to support security monitoring, accountability, and
traceability of messages to the source. This information will be used to provide accountability and
support for any required tracer actions. All stored audit data shall be maintained for at least ten (10)
days. Data will be recorded and stored at each MS to provide an audit capability for messages that are
delivered and submitted. The following table indicates which audit information is required at a minimum
to be logged by the MM-UA for delivered and submitted messages. National policy may require longer
retention periods and additional information be stored. The integrity of audit logs must be protected.
MS Logging Requirements
Delivered Messages Submitted Messages
Message Content Message Content
Message Delivery Envelope: Message Submission Envelope:
MTS Message Identifier MTS Message Identifier
Message Delivery Time Message Submission Time
Bind Arguments & Results Bind Arguments & Results
Report Delivery Envelope: Time of Indirect Submission
MTS Message Identifier
Report Delivery Time
Time of Retrieval from MS

CHAPTER 4
POLICIES AND PROCEDURES
SECTION I
GENERAL PROCEDURES
a. There are a number of procedures to be implemented in a military messaging environment

that may or may not correspond directly to a specific format field within the messages being transmitted
and received. This section describes those procedures and documents the methodology and
circumstances necessary for full implementation.
401. Clear Service
All MMs originating in the MMHS will incorporate the security services, included in the security
section of ACP 123. (See 4.II) However, there may be some instances where classified messages will
have originated outside the MMHS in the clear. In this case, on entry to the MMHS, the point of entry will
add the Clear Service. The message should be treated as CONFIDENTIAL even though the message
was originally received without a security classification. The Clear Service will be carried as part of the
Message Security Label, using the privacy-mark field. (See 2.II.207.h, 4.I.403.b). Messages with this
indication require the MM-UA to display to the recipient the words "RECEIVED IN CLEAR, TREAT AS
CONFIDENTIAL".
402. Recipients
It is the originator's responsibility to select the appropriate recipients for each message. It is
essential that the originator of a message limit the number of recipients to those who need to take action
thereon and, in the case of copy recipients, to those for whom the information contained in the message
is essential. Once the appropriate recipients have been determined, a Directory service may be used to
obtain the necessary recipient information required for proper addressing and security information. Upon
origination all recipients present in the envelope fields shall be indicated in either the primary, copy, or
blind copy heading fields.
403. Precedence Handling (local)
The extension fields primary-precedence and copy-precedence will be used to carry originator to
recipient information about the military importance of the message. Possible values for these fields are:
DEFERRED, ROUTINE, PRIORITY, IMMEDIATE, FLASH, and OVERRIDE.
a. Definitions of Precedence Levels
Six (6) levels of precedence are defined in ACP 123. However, the DEFERRED and
OVERRIDE levels of precedence are defined by ACP 123 but will not expected to be widely supported.
These values should be used only within the context of bilateral agreements. Additional precedence
values are also reserved for national use. The following levels of precedence are defined by ACP 123:
(1) FLASH – The FLASH precedence is reserved for initial enemy contact message or
operational combat messages of extreme urgency. Brevity is mandatory.

403.a (continued)
(2) IMMEDIATE – The IMMEDIATE precedence is reserved for very urgent messages
relating to situations which gravely affect the security of national/Allied forces or populace.
(3) PRIORITY – The PRIORITY precedence is reserved for messages concerning the
conduct of operations in progress and for other important and urgent matters when ROUTINE
precedence will not suffice.
(4) ROUTINE – The ROUTINE precedence is to be used for all types of messages which
justify transmission by rapid means but are not of sufficient urgency and importance to require a higher
precedence.
(5) DEFERRED – The DEFERRED precedence is lower than ROUTINE and left for
national policy or international agreement for further definition.
(6) OVERRIDE – The OVERRIDE precedence is higher than FLASH and is left for
national policy or international agreement for further definition.
b. Grade of Delivery
The primary-precedence field will automatically be used to select the associated Grade of
Delivery service. If both Primary Precedence and Copy Precedence indicators are present, and they
map to two different MTS Grades of Delivery, then multiple copies of the MPDU will be submitted (or the
MPDU may be divided by the originating MTA): one for the Primary Precedence recipients and the other
for the Copy Precedence recipients. If, however, the originating MTA can determine that all the Copy
recipients are served by delivering MTAs for Primary recipients, only one copy of the MPDU need be
transmitted with the MTS Grade of Delivery derived from the Primary Precedence. In the case of an
MM-UA not collocated with its originating MTA, the responsibility for two MPDUs would rest with the MM-
UA. The MM-UA would have to invoke two message submissions in order to ensure the proper Grade of
Delivery selection for appropriate recipients, as the message submission envelope does not carry an
indication of which recipients are Primary and which are Copy recipients. If there are no Primary
recipients, the Grade of Delivery is taken from the Copy Precedence. MPDUs for Blind Copy Recipients
will always be sent at a NON-URGENT Grade of Delivery. In messages that contain Blind Copy
Recipients, the MPDU may need to be submitted using up to three different Grades of Delivery
c. Determining Precedence
The assignment of precedence to a message is the responsibility of the originator. The

importance of judicious assignment (avoidance of use of a higher precedence than necessary) cannot be
overemphasized. The precedence assigned to a message by the originator does not necessarily indicate
the action to be taken by the addressee or the precedence designation that should be assigned to the
reply. Such instructions, if necessary, will be included in the text. The factors to be considered for each
message are:
(1) Consideration should be given to the urgency of the subject matter. Importance does
not necessarily imply urgency. The originator should consider the urgency of the message as it applies
to the addressee(s).
(2) Consideration should be given to the time difference between widely separate
geographical areas (e.g., Eastern United States is six hours behind Central Europe). Recipients with
MM-UAs not manned 24 hours/day, 7 days/week, may have requested auto-forwarding based on the
value of the priority field or invoked the Redirection of incoming messages EoS.

403.c (continued)
(3) If a message is auto-forwarded then, the auto-forwarded message shall have the
precedence level that applies to the recipient of the message.
d. Processing
All components shall process messages according to the Priority values in the envelope.
Messages with an URGENT Priority shall be processed before NORMAL, which shall be processed
before NON-URGENT messages. For each Priority level and destination, messages should be
processed in a First-In-First-Out (FIFO) order. No message of a lower Priority shall delay a message of
higher priority. Some examples of priority processing are:
(1) Multiple associations may be used to transfer messages simultaneously. Associations

established using network layer precedence mechanisms shall not be reused to transfer messages of
differing MTS Priority levels.
(2) Pre-emption may be useful in bandwidth constrained environments to meet the speed
of service requirements. Pre-emption is the suspension of the transmission of a message to allow the
transmission of a higher priority message with the resumption of the transmission of the suspended
message at the completion of the transmission of the higher priority message.
404. Message Acknowledgment
There are two levels of message acknowledgment that can be requested from originator to
recipient. The Request for Receipt Notification service will result in a service message, called a Receipt
Notification (RN), being returned from the recipient MM-UA after the message has been displayed to the
recipient. However, this is the equivalent of a recipient signing for a letter in the Physical Delivery postal
service. No authentication of the recipient is associated with this receipt notification. A receipt
notification does not imply an understanding of the contents, but simply that the recipient has accepted
responsibility for having received the message. If explicit Military Acknowledgment, which indicates that
the message has been "read and understood", is required, the originator shall ask for Reply Requested.
The originator may possibly include Reply By and Reply To (in the reply-time and reply-recipients
heading fields, respectively) indications. In this case, the recipient will generate a new message
indicating not only receipt, but also whether the received message has been understood. This new
message invokes security requirements and is the preferred acknowledgment method when
authentication of recipients is required. The following guidelines are recommended:
– Request for Reply shall be displayed to the recipient, so the recipient knows "Explicit
Military Acknowledgment" has been requested. If reply-time and reply-recipients fields
are present, these shall also be displayed to the recipient.
– Replies can be requested for both Primary and Copy recipients. However, the reply
request is only mandatory for Primary recipients.
– If the message recipient is a Primary recipient, then a reply shall be generated back to
the message originator or requested reply recipients before the time specified, if present,
or once the message has been read and understood, whichever comes first.
– If the Primary recipient does not respond by the time specified, the originator will
consider the message not received. It will be the responsibility of the originator to take
action to determine the cause of the failure according to national policy. This could be
contacting the recipient to ensure the original message was received or issuing a second
request for response. Audit logs can be used to initiate a tracer action if the message
was not received.

404.c (continued)
– If the message recipient is a Copy recipient, then generation of the reply is at the sole
discretion of the recipient (dependent on local policy).
– National policy shall specify the procedures for recipients that receive receipt
notifications, CSP signed receipt notifications, and reply requests.
405. Confirmation of Delivery
An optional service will allow an originator to ask the MTS to return a Delivery Notification
indicating the message was successfully delivered to the recipient MM-UA. This is strictly confirmation
of delivery at the MTA level, may not be authenticated, and does not indicate any sort of acceptance of
responsibility at the User level. Explicit message acknowledgment, or request for Receipt Notification,
shall be used if User acknowledgment of receipt of the message is required. In order to limit excessive
use of Delivery Notifications the following guidelines are recommended:
– for messages that map to the URGENT MTS Grade of Delivery (i.e., FLASH and
OVERRIDE), requesting Delivery Notification is encouraged, unless actual recipient
acknowledgment has been requested (e.g., Receipt Notification Requested or Reply
Requested).
– for messages that map to the NORMAL MTS Grade of Delivery (i.e., IMMEDIATE and
PRIORITY), requesting Delivery Notification is neither encouraged nor discouraged and
is solely at the discretion of the message originator.
– for messages that map into the NON-URGENT MTS Grade of Delivery (i.e., ROUTINE
and DEFERRED), requesting Delivery Notification is discouraged.
In all cases, it should be noted that non-delivery report will be returned to the originating MTA and the
non-delivery information will be given to the originating MM-UA unless the Prevention of Non-delivery
Notification EoS was requested with the message.
406. Cancellations
If a previously sent message is no longer considered valid, a second message indicating the first
has been obsoleted can be sent to all recipients. This will be implemented using the X.400 service
Obsoleting Indication. The body of the new message can either contain a replacement message or a
short message indicating the original message is no longer valid. Cancellation of a message may only
be done following the authentication policies of the originating nation. If a cancellation applies only to
some recipients of a message, then the body of the canceling message should indicate the nature and
limitations of the cancellation.
407. Corrections
If a previously sent message needs to be corrected, one of two methods may be used. If the
corrections are small compared to the size of the original message a new message, which describes the
changes and identifies the original message in the Cross-Referencing Indication, may be sent. The
second method is to transmit an entire replacement message indicating the original message to be
replaced in the Obsoleting Indication. Only the original message originator or the original release
authority is permitted to correct the previously transmitted message following the proper release and
authentication policies of the originating nation. In the case of partial corrections, appropriate references
shall be made to the specific location of the correction(s) within the body of the message (e.g., the
following sentence replaces the third sentence in the second paragraph of Section 10).

408. Repetitions, Checks, and Verifications
In the event that message integrity is lost resulting in corruption of a message, the recipient is
responsible for contacting the originator and requesting retransmission of the message. If it is necessary
to verify that all or part of a message is valid, a separate message may be sent.
409. Minimize
The purpose of the minimize procedure is to significantly reduce normal or routine message
traffic in specific regions or areas during times of crisis in favor of more essential, higher priority
message traffic. There is no explicit X.400 service defined to implement the Minimize capability;
however, Message Instruction (see 2.I.207.g) is defined to indicate that the originator has considered
Minimize. If the Message Instruction is present the message should, barring any delivery problems, be
delivered to the recipient. It is the responsibility of originators to enforce Minimize criteria. In the
MMHS, the Directory, or similar hard copy notification, will be used to ensure users are aware that
Minimize is in effect for potential recipients. It is still the originator's responsibility to ensure that only
mission essential messages are sent to a recipient in the Minimize affected area.
410. Message Cache
All users are procedurally required for locally storing complete copies of both outgoing and
incoming messages on-line for minimum of ten (10) days after submission and receipt. This is to support
the possible request for retransmission of a message and to support recipient inquires. After ten (10)
days have passed, stored messages will be archived in accordance with national records management
policy. Messages shall be stored with the original security services invoked since retransmission
requires the forwarding of the original message. If the message was originally encrypted, it must be
decrypted by the originator prior to retransmission.
411. Tracer Action
If acknowledgment of a message is requested and not received by an originator, then the user
can request a Tracer Action. A Tracer Action may consist of a request for operator assistance in
examining whatever trace information records are available. The method by which trace information can
be traced is a management issue that should be addressed by national policy. However, if an MMHS
domain can show from its trace information that a message was successfully passed to another MMHS
domain, they should expect the receiving domain to provide assistance in tracing the message to the
intended recipient.
412. Military Message Bodies
The actual information of an MM will be carried in the body of the MM. This can be formatted as
either a single body part or as multiple body parts. X.400 messages can carry many different types of
encoded body parts. To avoid misinterpretation and further explanatory messages, the message shall
state exactly what is meant and shall not be vague or ambiguous. The message should be as concise as
possible. If a military text format has been defined which is appropriate for use, that body part type will
be used. If no explicit military text format is appropriate a "free-formatted" text body part will be used
following the guidelines below.

412. (continued)
a. Sequence of Textual Matter
When a body part is free-formatted text the following guidelines will be used in preparing
the text:
– the security classification of the body part will be the first word(s) of the text, except that
the security classification may be preceded, when necessary, by appropriate
international alliance prefix/designator (e.g., COSMIC, NATO, etc.);
– if appropriate, the next text would be a list of references; (See 4.I.416)
– the remainder of the text of the message would follow.
b. Multiple Body Parts
When a message contains multiple body parts, possibly some of them in formats other than
plain text (e.g., graphics), the first body part will be "free-formatted" text and follow the format described
in 4.I.412.a. This part will provide an overview of the other body parts and action to be taken for each.
This descriptive text body part shall also be present in all messages conveying non-text body parts.
Every body part included shall contain within it, the appropriate security classification, prominently
displayed.
c. Military Body Part Types
A military ADatP-3 body part will be supported. Additional body parts may be required. For
example, each nation may want to define a national Military Text Format (e.g., USMTF) that can then
carry an identifier for the format as well as the actual text of the message. An MM can also be
forwarded.
413. Speed of Service
There are two different aspects to speed of service considerations. The first aspect is the need
for varying transfer speed requirements for the underlying infrastructure (i.e., the X.400 MTS). The
second aspect is the speed of handling of messages (i.e., originator to recipient). Both of these aspects
are tied to the precedence levels associated with the message. The transfer time is the difference
between the MTS submission time and the MTS delivery time. The originator to recipient time, which
includes the transfer time, is the time interval after the originator types the message and takes an action
to send the message recipient and when the intended recipient can view the message. Included in this
interval is the time needed for the application of security services, resolution of OR Addresses,
interconnection of components, submission to the MTS, transfer by the MTS, delivery by the MTS,
decryption of the message, validation of signature and signature path, and local handling. Speed of
service requirements for the originator to recipient time for the system must be guaranteed. The speed
of service times are further qualified with a maximum message size. The maximum message size is not
the largest size message that the system will be able to carry at each level, but rather the largest size for
which the required speed of service shall be guaranteed. A message character is equivalent to the
binary representation for the system in question (e.g., 1 character in ASCII = 1 byte [8 bits]). Total
message length, expressed in characters, does not include all required system and protocol overhead.
In addition to the message size, service is affected by the number of recipients selected. As such, the
speed of service shall be guaranteed only for predefined number of recipients. Definitive quantities
numbers will be provided when available. The following table indicates the supported precedence levels,
the corresponding originator to recipient speed of service requirements, the assumed message length,
the MTS Grade of Delivery, the derived MTS speed of service requirements, and message
retransmission times.

413. (continued)
Precedence Overall Requirements System Requirements

Originator to Assumed MTS Grade of Target MTS Deliver Message
Recipient Time Message Delivery Time Retransmit
Requirement Length* Time
OVERRIDE (5) 3 minutes 5,400 URGENT (2) As fast as possible, no 4 minutes
more
FLASH (4) 10 minutes 7,000 than 3 minutes 11 minutes
IMMEDIATE (3) 20 minutes 1,000,000 NORMAL (0) No more than 25 minutes
PRIORITY (2) 45 minutes 2,000,000 20 minutes 50 minutes
ROUTINE (1) No more than 8 2,000,000 NON-URGENT (1) No more than 8 hours, N/A
hours, or start of next or start of next business
DEFERRED (0) business day day
* = This message length (in characters) represents the maximum size for which the MTS Time of
Delivery must be guaranteed. The maximum size of messages supported is not constrained by this
document.
a. Speed of Transmission
In order for the precedence level to affect the speed of message transit through the MTS,
the selected precedence levels are grouped together and mapped to the Grade of Delivery Selection
upon submission. The target MTS delivery time for each Grade of Delivery is the time interval between
message submission and delivery (direct or indirect) that is required in order to meet the speed of
service requirements (i.e., the maximum time for delivery to meet the ACP 123 requirements if there
were no other components needed to perform messaging). If the transmission speed required of the
MTS cannot be met, the MTS shall continue trying to deliver the message as quickly as possible. Action
shall be taken to ensure delivery, possibly including: retransmission, tracer action, or transmission by
other means (applicable only for precedence levels of PRIORITY, IMMEDIATE, FLASH, and
OVERRIDE). If the Latest Delivery Time EoS was specified by the originator, then passing this time will
cause a Non-Delivery Notification to be returned to the originator. The MTS will also no longer attempt
delivery of the message. An MTA shall be configurable to allow a Non-Delivery Notification (NDN) after
a Maximum Non-Delivery Time has elapsed for any message. The time at which an NDN shall be
returned from the MTA may be measured either from the time of submission to the current time or the
time the message has been resident in a single MTA. When a message has been deemed
undeliverable, a Non-delivery Notification is returned to the recipient in the case of transmission system
problems where retries may succeed and Latest Delivery was not specified. How this default is
established, and whether operators are notified in case of transmission system problems are both
management issues that need to be addressed in national supplements.
b. Speed of Handling
Speed of handling includes everything from dictating physical delivery requirements to the
final action officer, to the order of messages displayed on an end-user workstation. Although these
criteria are viewed as local, non-communication oriented procedures, they cannot be implemented
without indicating the level of precedence in the message heading to the user. The Primary and Copy
Precedence EoS will be used to convey precedence information from originator to recipient.

414. Duplicate Detection
If the text of a message is an exact duplicate of an earlier message, but the IPMIdentifier or other
heading field in the second message is different (due to forwarding, autoforwarding, etc.), then the
message can not be detected as a duplicate by the system. The burden for recognizing a message of
this type as a duplicate will be on the recipient. However, if a UA receives two messages with the same
IPMIdentifier, the system can automatically determine the second message is a duplicate and discard the
second message. The user will be given an indication that a duplicate was detected and information
about the duplicate including its IPMIdentifier and Submission and Delivery Times, will be logged for
audit purposes. Automatic detection of this type of duplicate message is dependent on the local
implementation and availability of the earlier message within the UA's knowledge base. (E.g. if the
earlier message had been printed and deleted from the system, the UA may not have the knowledge to
determine that the second message contained a duplicate IPMIdentifier.) This duplicate detection
scenario will not work in the case of autoforwarded messages since autoforwarding from components
places a new IPMIdentifier on each autoforwarded message.
415. Conversion
Conversion is not compatible with originator-to-recipient integrity, authentication, and content

confidentiality. Implicit conversion will be used in the military environment where interface points are
utilized (e.g. tactical gateways).
416. References
a. When references are made to other messages that have been conveyed as MM, the
IPMIdentifier will be used as the reference. When referring to letters, orders, ACP 127 messages, and
other forms of military communications other than ACP 123 MMs, references will consist of the
authorized abbreviated title of the originator of the communication, followed by the identification of the
reference and its date (day, month, and year). When referring to an ACP 127 message, the SIC shall be
added.
b. When more than one reference is quoted, the originator may, if considered necessary,
identify each reference separately by a letter label. In this case the list of references should appear near
the top of the text body part of the message that makes use of those reference labels. (See 4.I.412.a)
c. When all the references are in the form of IPMIdentifiers, and the references are appropriate
to the entire message (i.e., all included body parts), the Cross-referencing Indication EoS should be
used. If the reference is only appropriate to one body part of a multi-body part message, the references
should appear near the top of that appropriate text body part. (See 2.II.202.i)
d. When references are placed in messages destined for several addressees, care must be
taken that such references are available to all addressees. In cases where a reference is not held by all
addressees and the originator determines that those addressees do not need it, then the indication
"(NOTAL)" (meaning "Not to, nor needed, by all addressees") should be included after the reference. In
this case the references need to appear in the body of the message. (See 4.I.412.a).
e. If the communications referenced are included as additional body parts to a message, this
will be indicated by appending the indication "(INCLUDED)" after the reference in the text.
417. Use of Alternate Delivery Mechanisms
Support for message redirection is impacted by the security services of ACP 120 (see 4.II.428).
The following sections clarify the effects of using all the forms of alternate delivery supported by X.400.

417. (continued)
a. Originator Requested Alternate Recipient
(1) Within the MMHS, two requirements have been identified for this EoS. The first
requirement allows the originator to choose an alternate recipient for each intended recipient of the
message in cases where the message does not reach the intended recipient as a result of message
transfer or delivery problems. The second requirement is for any message recipient within the MMHS to
be able to publish in the X.500 directory who his alternate recipient should be in cases where the
message does not reach the intended recipient. See 4.II.428 for a description of the interactions with
security services.
(2) Organizational users who may receive messages with precedence values of
IMMEDIATE, OVERRIDE, or FLASH may publicize an alternate recipient address; however, the
procedural requirements for publication of the alternate recipient shall be specified by national policy.
All message originators, originating messages with a precedence values of IMMEDIATE, OVERRIDE, or
FLASH, are procedurally required to honor and utilize the published alternate recipient selection of the
recipient, unless the Redirection Disallowed by Originator EoS (see clause 202.ah) has been selected by
the originator. Use of this particular mechanism is discouraged for short-term redirection of messages
(e.g., between the beginning and end of users shift, stoppage of work [i.e., lunch, meetings, etc.], certain
tactical situations) by recipients because of a dependency on timely updates of the directory. Short-term
redirection by recipients are better handled through the autoforwarding EoS. Subsequent redirection
operations (e.g., when alternate recipient is also unavailable) will not be supported by this mechanism.
In cases where more than a single tier of redirection coverage is required, other options must be used.
b. Redirection of Incoming Messages
The Redirection of Incoming Messages service may be used by prospective recipients to

designate an alternate for their particular MM-UA for an agreed period of time. This type of redirection
applies to all incoming traffic that has been correctly addressed to the recipient MM-UA in question. See
4.II.428 for a description of the interactions with security services.
c. Alternate Recipient Assignment
The Alternate Recipient Assignment service may be used to designate a "default mailbox"
(e.g., PostMaster) for a particular part of the OR Addressing tree. This type of redirection applies to
messages for which a delivery decision cannot be made. It can only be assumed that the default
mailbox administrator will be able to make decisions based on the envelope fields (see 4.II.428).
Establishment of this EoS must occur as an agreement between the messaging user and the delivering
MTA service provider through non-standard means (e.g. service type agreements). International use of
this mechanism is discouraged because a Non-delivery report to the originator is preferable to a default
mailbox receiving it. Use of this service will be defined by national policy.
d. MS Autoforwarding
The MS Autoforwarding service may be used to designate an alternate for a particular

recipient MM-UA. This service is encouraged for users who are required to retain a copy of all messages
delivered to their MM-MS. This type of redirection applies to all incoming traffic that has been correctly
addressed to the recipient MM-UA in question including any one of the redirection mechanism described
above. The new recipient will be alerted that the message was autoforwarded by the Auto-forwarded
Indication (see clause 2.II.202.d). If the originator has requested a non-receipt notification, one will be
returned that may contain the reason why the intended recipient enabled autoforwarding. Further
autoforwarding rules can be made based on the mt-message-submission-time and mt-priority attributes
carried in the message delivery envelope. Note that this redirection mechanism is the most flexible;

417.d (continued)
however, it is slower compared with the other mechanisms because the message must first be delivered
to the MS before it can be forwarded. See 4.II.428 for a description of the interactions with security
services.
e. UA Autoforwarding
The availability of the MM-UA autoforwarding service shall be defined by national policy. If
MM-UA autoforwarding is supported, then the MM-UA shall support the Auto-forwarded Indication EoS.
SECTION II
SECURITY
a. Although this particular section may be documented separately from ACP 123, it is
anticipated that both protocol and procedural issues related to security will require some degree of Allied
agreement. This section describes generic security requirements independent of the mechanisms used
to provide the security. It is recognized that gateways may be required to facilitate interoperability
between national systems that adopt different security solutions. Incompatibilities may arise due to the
selection of different security mechanisms, cryptographic algorithms, or key management strategies. In
this event, it may not be possible to provide these security services directly between the originator and
the intended recipients in the strict X.400 sense. Therefore, the definition of both the message originator
and the intended recipients may be refined subject to bilateral or multi-national agreements. The
following security services will be supported.
418. Message confidentiality
This service protects against unauthorized disclosure of the message.
419. Message integrity
This service provides a method of ensuring the content that was received is the same as that
which was sent by the originator.
420. Data origin authentication
This service provides assurance that the message was originated by the user indicated as the
sender.
421. Access Control
This service validates authorization of the user originating and receiving messages. Access
control implementation details are a local matter. Messages both sent and received shall not violate the
security policies of the originators and recipients.
422. Message Non-repudiation with proof of origin
Non-repudiation provides the recipient with evidence that demonstrates, to a third-party, who
originated the message, and will protect against any attempt by the message originator to falsely deny
having sent the message. This evidence is the proof of origin of the message, which is a digital
signature and the certificates necessary to verify it. However, to preclude a subsequent denial by the
originator of having sent the message, the digital signature for this particular message must not be

422. (continued)
effected by subsequent revocations of the originator's certificates. To preserve this evidence, additional
records management procedures must be applied. These include trusted timestamps with another
signatures, and audit logs.
423. Message Non-repudiation with proof of delivery
Non-repudiation provides the originator with evidence that demonstrates, to a third-party, who
received the message, and will protect against any attempt by the message recipient to falsely deny
having received the message. This evidence is the proof of delivery of the message, which is a digital
signature and the certificates necessary to verify it. However, to preclude a subsequent denial by the
recipient of having sent the message, the digital signature for this particular message must not be
effected by subsequent revocations of the recipient's certificates. To preserve this evidence, additional
records management procedures must be applied. These include trusted timestamps with another
signatures, and audit logs.
424. Message Security Labeling
This service provides a method for associating Security Labels with objects in the MHS. This
then allows a Security Policy to define what entities can handle messages containing associated Security
Labels. The Security Label associated with a message shall also indicate the Security Policy to be
followed.
425. Accountability
This service ensures that all actions taken on a message from release by the originator to
viewing by the recipient are recorded.
This service prohibits users from finding out information about potential recipients on the network
without the knowledge of the recipient. This service shall be implemented by MMHS interface points into
ACP 123 MHS domains to block probes from entering the ACP 123 MHS.
427. Security Classification
a. Responsibility
It is the responsibility of the originator to ensure that the proper classification is indicated on
the message. A reply or reference to a classified message may be assigned a lower classification when
the contents of the text of the message containing the reply or reference permits.
b. Classifications
Messages are to be classified TOP SECRET, SECRET, CONFIDENTIAL, or RESTRICTED

whenever their content falls within the definition set forth in appropriate national regulations. Messages
bearing no security classification should be marked UNCLASSIFIED or the abbreviation UNCLAS. The
abbreviation of UNCLAS is valid only in conjunction with the procedural requirement to place the
classification in the first line of text. If a X.411 security label is utilized, UNCLAS will be represented as
UNCLASSIFIED with an integer value of 1. The security classification of a message shall be displayed
to the user at all times during processing of the message. National regulations shall also dictate the
policies for marking security classifications on individual paragraphs or body parts within a message.

427. (continued)
c. Security Label
The security label assigned to the entire message will be that of the highest classification of
any part of the message or the appropriate label for the aggregate of the information contained in the
entire message including all body parts. The security label will be defined by a security policy. The
determination as to whether it is national policy or a multi-national agreed policy is considered outside
the scope of the ACP 123.
428. MM and MT EoS Interaction with ACP 120 EoS
Interaction of security services with certain MT, MM, and MS EoS require special considerations
be taken in order to provide the EoS to the MTS users. Messages must be decrypted before any of the
MM EoS may be provided to MTS users. The following clauses identify the considerations that shall be
taken in order for MT and MM EoS to be provided in an ACP 120 environment.
a. Alternate Recipient Allowed
This MT EoS enables an originating UA to specify that the message being submitted can be
redirected or delivered to an alternate recipient. This MT EoS shall not be used as a means of access
control as it cannot be assured that the recipient will not receive the message as the result of redirection,
DL expansion, etc.
b. Blind Copy Recipients
This MM EoS enables the originator to provide the OR Descriptor of one or more additional
recipients of the message being sent. These names are not disclosed to the primary, copy, or other blind
copy recipients. This MM EoS shall not be used as a means of access control as it cannot be assured
that the blind copy recipients will not be disclosed to other primary, copy, or blind copy recipients as the
result of redirection, DL expansion, etc.
c. Clear Service
ACP 120 provides a security label, which includes the privacy mark, only when the message
is encrypted. Clear service can only be provided if the message is encrypted.
d. Conversion
When a message is either encrypted or signed conversion, either implicit or explicit, will
negate any provided security services. Message originators that encrypted or signed messages shall
ensure that the Conversion Prohibition EoS is invoked thereby ensuring conversion does not take in the
MTS. If the Explicit Conversion EoS is available to the user, the conversion prohibition in case of loss
of information EoS shall not be invoked.
e. Deferred Delivery
The deferred delivery EoS may impose significant message delivery delays. If security
services are applied, the originator shall ensure that their certificate is valid for the anticipated message
delay period or the recipient may be unable to perform security processing upon message reception.

428. (continued)
f. Exempted Addresses
This MM EoS is used to convey the names of members of an AL that the originator has
specified are to be excluded from receiving te message. This EoS shall not be used as a means of
access control as it cannot be assured that the exempted addresses will no receive the message as the
result of redirection, DL expansion, etc.
g. Hold for Delivery
This MT EoS enables a recipient UA to request that the MTS hold its messages and
returning notifications of delivery until later time. If security services are applied, the recipient shall
ensure that the hold for delivery time is less than the anticipated validity period of the originator’s
certificate or the recipient may be unable to perform security processing upon the message.
h. Redirection Disallowed by Originator
This MT EoS enables an originating UA to instruct the MTS that redirection should not be
applied to this particular message. If the originator requests redirection be disallowed, the recipient may
still specify an alternate recipient receive the message via an autoforwarding service (i.e., this EoS does
not guarantee delivery to only the intended recipient). See 4.I.417 for additional information.
i. Use of Distribution Lists
Originators should be aware of whom they are addressing messages and the recipients of
the DL because a DL cannot be distinguished from another OR address. Where the DL is expanded is
up to security policy.
j. Use of Alternate Redirection Mechanisms
In order to allow alternate recipients access to messages that have been protected by ACP 120 security
services and redirected through any of the alternate delivery mechanisms, the alternate recipients must
possess the same key material as the original recipient or the alternate recipients key material must be
transmitted with the message. The intended recipients key material is contained within a certificate and
must be made available to the message originator. The following clauses specify additional procedural
requirements dealing with the alternate delivery mechanisms that will ensure alternate recipients can
access the messages.
(1) Originator Alternate Recipient - Use of this EoS in the ACP 120 security environment
requires the originator of the message to include the intended recipients and alternate recipients, if
alternate key distribution methods have not been used for the alternate recipients, in the original
message for the message to be decrypted by the specified recipient.
(2) Redirection of Incoming Messages - If the incoming message has been protected by
ACP 120 security services and is redirected to an alternate recipient, the alternate recipient is required to
posses the same key material as the original recipient or the alternate recipient key material must be
transmitted with the original incoming message if the alternate recipient requires access to the message.
In addition, redirection of messages with confidentiality applied in the MTS can only be based on
information in the message envelope.
(3) Alternate Recipient Assignment - When Alternate Recipient Assignment is used, the
default mailbox administrator may be capable of accessing the content of secure messages provided
that adequate provisions have been made by the security infrastructure.

428.j (continued)
(4) MS Auto-forwarding - Because the security label of the message is unavailable to the
MS, messages may be forwarded to a secondary recipient who is unable to process the message dues to
inconsistencies between the user authorizations and the message’s security label. Recipients of the
forwarded message may be capable of accessing the content of secure messages provided that
adequate provisions have been made by the security infrastructure.
SECTION III
NAMING AND ADDRESSING
a. Users of MMHS are identified by OR Names, which consist of either an OR Address, a

Directory Name, or both. The OR Address is used for routing messages to recipients within the Message
Transfer Service, by locating MTAs required to take the message closer to its destination. In this way,
the OR Address is related to the MTA Routing Architecture. Directory Names reflect the hierarchical
structure of the users of MMHS. Although some of the attributes used in OR Addresses and Directory
names may be the same (e.g., Organization name) there is not necessarily a one-to-one mapping
between the values used for those attributes in the two contexts. In the absence of a Directory Name,
the OR Address serves to name originators or recipients. Therefore, the distinction between Naming and
Addressing is not always entirely clear.
429. O/R Addresses
a. The Mnemonic and Numeric forms of OR Address (as defined by X.402) shall be supported
by all MM-UA and MM-MS elements. OR Addresses shall be present in the P1, P3, and P7 envelopes
and in the P772 content. The address support requirements for MTAs are addressed by AMH1n(D).
b. Guidelines for determining what goes in the Organization and Organizational Unit attributes
and how these might be derived from the PLAs will be defined by policy of appropriate registration
authorities. Registration authorities will be determined by national policy or multi-national agreement.
c. Two Military Domain Defined Attributes (DDAs) are used in interworking with the ACP 127
domain. Support for generating and displaying these DDAs when part of an OR Address is mandatory.
The use of these DDAs is optional when defining the OR Address of any given user. If ACP 127 users
are not registered in the MMHS, then those users will be identified by the OR Address of the ACP 127
gateway together with the PLAD or RI (or both) of the user. In such cases, the PLAD and RI of the user
will be carried as DDAs. The use of these DDAs is transitional, and may only be used while interworking
with ACP 127 messaging is required. These Military DDAs are:
Domain Defined Attribute Type Value
PLAD ACP-PLAD ACP-address including but not limited to:
PLADs, SMAs, AIGs, and CADs
RI ACP-RI Any ACP 127 RI, including collective RIs
d. The Domain Defined Attributes will not be used for inter-domain routing purposes.
430. Directory Names
A Directory Name can be used to identify originators and recipients in the content of messages
within the MMHS in a more user friendly manner than using OR Addresses. In order for messages to be

430. (continued)
delivered via the MTS, the correct OR Addresses must be present in the envelope (directory names
alone are not sufficient). It is the responsibility of the originating domain to ensure that the correct OR
Addresses are present. The directory name shall be present in both the P1, P3, and P7 envelopes and
in the P772 content.
431. Address Lists
This section addresses the unique requirements involved with short-hand methods of addressing
lists of recipients. An AL is a form of military recipient designator representing a predetermined list of
specific and frequently recurring combinations of primary and copy recipients. The purpose of ALs is to
reduce the length of the address component. ALs can be used whenever suitable, irrespective of the
classification of the message concerned or the security mechanism used. ALs may be carried as OR
Names in the primary-recipients or copy-recipients fields, or in the address-list-indicator field. (See
2.II.208.f)
a. List Expansion
The AL expansion is the responsibility of the originating domain except by agreement. For
example, some ALs may be expanded in the recipient domain. List expansion shall consider associated
exempted addresses. There are two types of mechanisms that can be used to perform list expansion.
These are source expansion and remote expansion.
(1) Source Expansion – the originating UA performs expansion of ALs prior to submission.
The expanded list of recipients shall be indicated within the content in the appropriate heading fields.
Any exempted addresses (see clause 2.II.207.d) included in the heading shall be considered in the
source expansion. Allowable variations of this mechanism allow the originator's MS or MTA to perform
the expansion (i.e., in a client-server or other colocated environment) provided that the expansion is
performed prior to application of security mechanisms. When source expansion is used, the address-list-
indicator field may be used to indicate the name(s) of the ALs used in the source expansion. Use of the
address-list-indicator field to support this is for transition only.
(2) Remote Expansion – the originating UA addresses the message to a well defined OR
address associated with the AL. Security mechanisms shall then be applied to protect the message en
route to the AL expansion point. The message is then submitted and the MTS conveys the message to
the AL expansion point. The AL expansion point shall examine the message and expand the AL. Any
exempted addresses (see clause 2.II.207.d) included in the heading shall be considered in the
expansion. Disruptions in the security mechanisms shall be minimized, and shall be limited to the extent
necessary to allow the expanded list recipients to access the message. The MM content heading shall
indicate the AL names themselves rather than the AL member names. The expanded list of recipients
shall be indicated in the envelope.
b. Owner
Responsible commanders and authorities may request assignment of an AL to a fixed

combination of recipients to which messages are frequently addressed. The command or authority
requesting assignment of an AL will assign a cognizant authority to be the owner of that AL. The owner
is responsible for maintaining the AL and reviewing it at least quarterly for continued requirement and
necessary modification. Requests for permanent modifications by other than the owner shall be
forwarded to the owner to insure that the requested modifications do not detract from the intended use of
the AL.

431.b (continued)
c. Notifications
If a Receipt or Non-receipt Notification is requested for a recipient specified as an AL, the

notification returned indicates whether or not the list was successfully expanded and the originator had
the appropriate submission privileges to use the AL as a recipient. The AL owner controls the policy of
the AL which indicates whether reports received about delivery to members of the list are forwarded to
the originator of a message. The owner is discouraged from propagating reports from the members of
the AL to the originator of the message.
d. Titles
A concise AL descriptive title may be included in the directory entry supporting the AL.
Descriptive titles assigned to ALs do not preclude use of a particular AL for other type messages,
provided the text sufficiently identifies the message as other than that shown in the descriptive title.
e. Use
If all addressees of a particular message are not contained in any AL, the most appropriate
AL may be selected and Primary or Copy recipient(s) may be added to or exempted from the address
using the appropriate recipient designators. There is no limit upon the number of recipients that may be
added to or exempted from the address of an AL. However, care must be taken not to create a longer
recipient list using ALs and exemptions than would be required if individual recipient designators were
used for all recipients. If the same list of recipients is to be added to or exempted from the composition
of an AL regularly, the AL should be modified, or a second AL defined.
432. Directory Services
a. The Directory service (also known as "the Directory") is expected to play a significant role in
the successful implementation of the X.400-based MMHS. The ACP 133 will specify the Directory for
use by MMHS. The Directory will support a number of critical functions that will be used to support
everything from OR Name lookup to distribution of the user certificates necessary to support various
encryption algorithms.
b. Registration Authorities shall be established following appropriate national procedures.

Addressing information for registered MMHS users shall be published and made available to other
MMHS users authorized to originate messages to them.
SECTION IV
MANAGEMENT
a. Military Messaging in MMHS will be possible by the interconnection of MMHS MDs within
the different nations. The actual management of each of these MMHS MDs will follow national or local
policy. However, some cooperation will be required in order to meet the quality of service requirements
specified in this ACP.
433. Accounting policies and procedures
Bilateral agreements may need to be arranged to support requirements for accounting policies
and procedures across national boundaries.

434. Trace and Accountability
The MMHS is required to provide assurance that messages sent are received by the intended
recipient(s), or that the originator is notified of any problems with delivery. During normal operation of
the MMHS, messaging services are employed to satisfy this requirement. In the event of certain system
failures, however, messaging services may not provide adequate assurance. Therefore, additional
capabilities are required nationally to maintain an audit trail sufficient to provide inter-domain trace and
accountability functions. To satisfy this requirement in the event of failures, it is recommended that
several MMHS components log audit trail information. A management system shall provide the
capability of accessing this audit trail and exchanging necessary trace information across international
domain boundaries. Combining the allocation of responsibility for ensuring messages have been
received, and the maintenance and management of audit trail information act in concert to provide
accountability in the MMHS.
a. Accountability Requirements
Accountability will be provided to MMHS users by audit utilities and tracer actions. MMHS
users should be assured that the MMHS will deliver messages in a timely manner to the intended
recipients with the proper security mechanisms intact. If the MMHS does not perform these functions in
a satisfactory manner, the user may request that system managers identify the portion of the system that
that caused the degraded performance. The request will invoke audit utilities and tracer actions to
provide system accountability. Note that across international domain boundaries, the resolution of the
accountability is not required to extend below the domain level. Within nations boundaries, identification
of the specific component, process, or user that caused the degradation may also be possible.
b. Audit Trail Information Management
Audit utilities will provide a detailed record of system activity to facilitate reconstruction,
review, and examination of the events surrounding or leading to mishandling of messages, possible
compromise of sensitive information, or denial of service. Local policy shall be developed that explains
which actions are to be taken when discrepancies are found. The management function should be able
to identify the following events:
– Messages delivered after the required Speed of Service time has elapsed
– Messages not retrieved from the MM-MS for a specified time
– Messages retrieved but not read for a specified time
– Messages submitted but not delivered
– Message signature verification failures
– Probes submissions or transfers attempted
– Peer-entity authentication failures
– User authentication failures
– Violations of the security policy.
Information shall be maintained by management system for ten (10) days.
c. Tracer Action
This paragraph describes how a tracer action can be initiated and under which
circumstances it will be used. If acknowledgment of a message is requested and not received by an
originator, then the user can request a tracer action. A tracer action may consist of a request for system
operator assistance in examining whatever audit trail records are available. Alternatively, a system

434. (continued)
management function may be used by a system manager to access remote audit trail logs to determine
the exact disposition of the message in question. Tracer actions should be initiated within ten (10) days
of the perceived problem to facilitate usage of audit data stored on-line at local components; however,
procedures and guidelines for initiating tracer actions may vary depending on the specific environment in
question (e.g., multiple tactical environments, strategic environments).
d. Interdomain Trace Operations
If a domain can show from its audit logs that a message was successfully passed to another
domain, the domain that passed the message forward should expect the receiving domain to provide
assistance in tracing the message to the intended recipient. Bilateral agreements may be necessary to
coordinate tracer actions across national boundaries. The interface points with other national systems
shall maintain the information necessary to support interdomain message tracing and accountability.
435. Performance management
In order to meet the speed of service requirements each MD will be responsible for monitoring
the performance of the MTS within its domain. This could be accomplished by either performance or
fault monitoring. If faults occur that the transfer speeds can no longer be met within that MD, it may
affect messages originating or destined for users in other MDs. Although these factors are strongly
dependent on the overall system architecture, the management system will need to include procedures
to ensure that these requirements are being met. The procedures should describe the actions that will be
taken if problems are detected.
a. Transfer Delay
Transfer delay is the delay incurred during transmission of a message either through an
individual MTA or through the MTS. MTA transfer delay is the difference between the time a message
enters an MTA and the time the message leaves the MTA. MTS transfer delay is the difference between
the message’s submission and delivery time. The management system should strive to keep both MTS
and MTA delays minimal to ensure that the speed of service goals are met.
b. Connection Establishment Delay
Connection delay is the time needed to establish the initial dialog between two platforms
(e.g., MTA to MTA, MTA to MS, MTA to UA). This delay should be minimized to achieve the Grade of
Delivery associated with the precedence level of the message.
c. Storage Availability
Various components, including primarily the MTA and MS, will require sufficient storage
space for receiving and transferring messages. The management functions shall provide for the
monitoring of available storage space. The management system shall initiate corrective action when
storage availability falls below a nationally defined threshold.
436. Configuration Management
Configuration management will be performed according to national or local policy. However,

bilateral agreements will be necessary to ensure that changes to the configuration of one nation's MTS
which may impact the operation of another nation's MTS will be mutually agreed upon before
implementation.

CHAPTER 5
Profiles
a. Chapters 2 and 4 define the services provided in the MMHS and the policies and
procedures to be used with these services. This chapter provides additional information about which of
the services and procedures apply in specific military environments. In chapter 2 if an element of
service is specified as optional, an implementation can still claim conformance to military messaging if it
does not implement that service. In the following sections, if a profile states that some of those optional
EoS shall be supported, an implementation cannot claim conformance to the specified profile without
implementing those optional EoS.
b. If additional policies or procedures are required in order to conform to the specified profile,
these additional requirements are also defined in this chapter.
SECTION I
Taxonomy
a. The profiles specified by this ACP are organized according to a taxonomy similar to the
International Standardized Profile (ISP) taxonomy defined by ISO/IEC TR 10000. The taxonomy defines
the relationship between each of the profiles required to implement the MMHS. Two relevant types of
profiles are included in the taxonomy: A-profiles which specify the requirements for connection-oriented
applications and F-profiles which specify the requirements for abstract information objects conveyed by
A profiles. If a requirement for connectionless application profile is identified it may be included as a B
profile. The relevant portions of the ACP taxonomy are depicted in Figure 5-1.
501. A-profiles
a. A-profiles define requirement for connection-oriented applications. The "MH" branch of the
taxonomy identifies requirements for connection-oriented MHS applications. Each MHS application is
assigned a number. Under each MH branch, there are three profiles to list the MMHS requirement on
the three PDUs defined in X.400, MTA Transfer Protocol (P1), MTS Access Protocol (P3), and MS
Access Protocol (P7). Two additional parts, which contain no profiles on their own, are also part of the
multi-part profile to list common MMHS service support and MMHS requirements for Reliable Transfer
Service Element (RTSE), Remote Operation Service Element (ROSE), Application Control Service
Element (ACSE), and presentation and session protocols.
b. The ISO/IEC ISP 10611 defines a broadly recognized set of requirements for MHS support.
The ISO/IEC ISP 10611, which is titled "Common Messaging", is a multi-part profile that specifies the
requirements for the entire taxonomy branch AMH1n. The ISO/IEC ISP 10611 consists of the following 5
parts:
– Part 1 – MHS Service Support

– Part 2 – Specification of ROSE, RTSE, ACSE, Presentation and Session Protocols for
use by MHS
– Part 3 – AMH11 – MHS Requirements for Message Transfer (P1)
– Part 4 – AMH12 – MHS Requirements for MTS Access (P3)
– Part 5 – AMH13 – MHS Requirements for MS Access (P7).

501. (continued)
c. For the Standard Profile described in 5.II, the number "1" has been assigned to the MMHS
Common Unrestricted Messaging. The multi-part profile included in Annex C of this ACP is referred to
as AMH1n(D)7. The A-profiles defined by this ACP are presented as "deltas" to the ISO/IEC ISP 10611.
The multi-part profile has the following five parts:
– Part 1 – MHS Service Support

– Part 2 – Specification of ROSE, RTSE, ACSE, Presentation and Session Protocols for
use by MMHS
– Part 3 – AMH11(D) – MMHS Requirements for Message Transfer (P1)
– Part 4 – AMH12(D) – MMHS Requirements for MTS Access (P3)
– Part 5 – AMH13(D) – MMHS Requirements for MS Access (P7).
d. Other A-profiles may be included in later revisions to document MMHS Low-throughput

Messaging8.
502. B-profiles
a. If a requirement for a connectionless applications profile is identified the profile may be

included as a B profile.
b. B-profiles list requirements on connectionless applications. The "MH" branch of the

taxonomy identifies requirements for connectionless MHS applications. Each MHS application is
assigned a number.
c. There are currently no civilian ISPs for connectionless MHS.
d. Future versions of this ACP may include a profile to document the requirements for the
restricted profile described in 5.III.
503. F-profiles
a. F-profiles specify requirements for abstract information objects conveyed by A and B

profiles. Abstract information objects conveyed by A and B profiles include: MM content type, and MS
attributes.
b. This ACP specifies five F-profiles in Annexes D through H as follows:
– FMH11(D) – MM content (P772)

– FMH20(D) – General MS Attributes
– FMH21(D) – MM-specific MS Attributes
7 The "D" stands for Defense.
8 This environment has yet to be defined; however, it is envisioned that it will embody connection-
oriented applications constrained by low-throughputs.

1 1 - Message Transfer (P1)

Common
Unrestricted 2 - MTS Access (P3)
Messaging
A MH 3 - MS Access (P7)
Connection Message
Mode Handling
Applications Systems 1 - Message Transfer
2
Low Throughput 2 - MTS Access
Messaging
3 - MS Access
B MH 1
Connectionless Message Simplex,
Mode Broadcast,
Handling
Applications & Low Throughput
Systems
1 - Military Messaging (P772)

1
Content
Types 2 - Common Security Protocol (CSP)
F MH
3 - EDI Messaging (Pedi)
Information Message
Representation Handling
Systems
1 - Military Messaging (P772)
2
Message
Store 2 - Common Security Protocol (CSP)
Attributes
3 - EDI Messaging (Pedi)
Figure 5-1 Profile Taxonomy

SECTION II
Standard Profile
504. Profile Definition
a. This MMHS Standard Profile specifies any additional required behavior of Message
Handling Systems providing the ability to perform Military Messaging in an environment essentially
unrestricted by bandwidth considerations. The required characteristics of MMHS as specified in
Chapters 2 and 4 of this document apply as the base requirements for Military Messaging. AMH1n(D) in
Annex C specifies the standard profile. This is expected to be the normal environment for Military
Messaging where services to satisfy standard military requirements for messaging are expected to be
available to users of the system.
505. Implementation Requirements
International messaging between nations is expected to be achieved via the following three types of
interfaces:
– P1 interface
– P3 interface
– P7 interface
In order to promote basic interoperability, all nations are required to support the P1 interface
requirements. Support for the P3 and P7 interface requirements are optional.
The following are conformance requirements for the three types of interfaces. Note profiles identified
by the prefix "FMH" are information representation profiles for which conformance is strictly independent of the
identified interface.
a. P1 Interface: Nations are required to demonstrate conformance to the following profiles:
– AMH11(D)
– FMH11(D)
b. P3 Interface: Nations are required to demonstrate conformance to the following profiles:
– AMH12(D)
– FMH11(D)
c. P7 Interface: Nations are required to demonstrate conformance to the following profiles:
– AMH13(D)
– FMH11(D)
– FMH20(D)
– FMH21(D)
d. P1 Interface: If Nations claim to support security services provide by ACP 120

– FMH12(D)

505. (continued)
e. P3 Interface: If Nations claim to support security services provide by ACP 120

– FMH12(D)
f. P7 Interface: If Nations claim to support security services provide by ACP 120

– FMH12(D)
– FMH22(D)

(Reverse Blank)
UNCLASSIFIED ANNEX A to ACP 123
Annex A
Military Messaging Content Type
This annex is written as a delta document to the CCITT X.400 Series Recommendations defines the
enhancements and modifications to X.400 required for Military Messaging. This annex is the same as
Annex A of STANAG 4406. Keeping the definition of the actual protocol for MM the same in both ACP
123 and STANAG 4406 ensures there is only one definition of the MM content type for use in the Allied
community.
MMHS EXTENSIONS
UNCLASSIFIED A-1 ORIGINAL
ANNEX A: MILITARY MESSAGE HANDLING SYSTEM EXTENSIONS
INTRODUCTION
(NU) The Military Base Standard (MBS) is defined by a set of extensions to the civilian
Message Handling System standard [X.400 | ISO/IEC 10021] which are required for
Military Messaging (MM). This standard fully supports the Interpersonal Messaging
defined in the civil X.400 standards (i.e. both P2 and P22 Content types) as well as the
Military Messaging defined by these extensions.
(NU) The military extensions are achieved using the standard extension mechanisms
defined in [X.400 | ISO/IEC 10021]. This approach defines military-specific semantics in
the extensions. The semantics of the civil standard are not changed. This STANAG does
not redefine the civil semantics. It is therefore a superset approach of the civil standard.
If nations have requirements for additional national or bilateral extensions they should
adopt the same approach in developing a superset of the MBS.
(NU) In order to highlight the military extensions and avoid duplication of text in the
civilian standards, a delta document approach has been taken. The sections of this
annex follow the same structure as the civil MHS standard [X.400 |ISO/IEC 10021-1] to
which they correspond. Each of the sections of this Annex identifies any necessary
extensions and restrictions to the corresponding section of the civil standard. This
technique provides traceability and puts the delta text in context.
(NU) Unless exceptions are noted, all statements which apply to Interpersonal
Messaging Services (IPMS) also apply to Military Messaging Services (MMS). The
reader should therefore make this mental substitution when reading the civilian
standards which form the base upon which the military delta requirements are overlaid.
(NU) The military extensions to [CCITT X.400 |ISO/IEC 10021] series of documents are
summarized as follows:
MMHS Extensions of [X.400 | ISO/IEC 10021-1]
(NU) This section identifies the extensions required to the System and
Service Overview of MHS to accommodate MMHS. It includes an
overview of the additional services and the specialized use of existing
features;
(NU) This section identifies the extensions required to the Overall

Architecture of MHS to accommodate MMHS. In particular the
extensions required for naming and addressing are described here;
(NU) No extensions are necessary
(NU) This section identifies the extensions required to the Message

Transfer System Definition and Procedures of MHS in order to support
MMHS;
MMHS EXTENSIONS
(NU) This section identifies the extensions required to the Message

Store Abstract Service definition of MHS in order to support MMHS;
(NU) No extensions are necessary
(NU) This section identifies the extensions required to the Interpersonal

Messaging System of MHS in order to support MMHS.
MMHS EXTENSIONS
MMHS EXTENSIONS TO [X.400 | ISO/IEC 10021-1]
SECTION 1 – INTRODUCTION
1 SCOPE AND FIELD OF APPLICATION
(NU) This standard pertains to the communications aspects of Military Message

Handling. The local interfaces, such as the human computer interface, are not part of
this standard.
2 REFERENCES
MMHS Intercept Interoperability Functional Profile
CCITT X.400(1984)
ITU X.400 (1992)
ITU Implementors' Guide, Version 11
ACP 121
ACP 127
ACP 128
ACP 131
APP-3
3 DEFINITIONS
MMHS - Military Message Handling System - The purpose of MMHS is to convey

military messages between military organizations or individuals.
MMS - Military Messaging Service - The purpose of MMS is to provide an

electronic mail like service to staff units and individual users in military
organizations which fulfills established military requirements for
messaging systems.
MM - Military Message - The military information object supported by the

MMS.
MMTA - Military Message Transfer Agent - The functional object that

provides the store and forward transport of a MM.
MMTS - Military Messaging Message Transfer System -The functional

object, composed of MMTA's, that conveys information objects to
organizations, to subscribers, or to distribution list members.
MM-UA - Military Messaging User Agent - The functional object by means of

which an organization or subscriber engages in military message
handling.
MM-AU - Military Messaging Access Unit - The functional object that links another
communication system to the MMTS.

MM-MS - Military Messaging Message Store - The functional object that provides
an organization or subscriber with capabilities for message storage and
retrieval.
SECTION 2 – GENERAL DESCRIPTION OF MHS
7 FUNCTIONAL MODEL OF MHS
8 THE MESSAGE TRANSFER SERVICE
(NU) One of the principal reasons for developing MMHS as an extension of MHS is to
minimize cost by taking advantage of well-known standards and their related products. It
is, therefore, desirable to minimize, and if possible eliminate, any extensions to the P1
protocol as specified in the civilian standards. Also, in order to promote interoperability
with other MHS-based systems, it is desirable to incorporate MMHS extensions not as
reinterpretations of existing services and protocol elements but as new fields and
elements. These are sometimes competing mandates. The MMHS extensions are
identified as deltas to [X.411 | ISO/IEC 10021-4].
9 THE MM SERVICE
(NU) The Military Messaging Service (MM Service) is similar to the IPM Service defined
in the civilian standards. It includes extensions for services required in the military
environment. These extensions are defined in the MM Extensions to [X.420 | ISO/IEC
10021-7].
9.1 MM Service Functional Model
(NU) The MM service functional model is slightly different from the one defined in [X.400
| ISO/IEC 10021-1]. The MM service functional model is shown in Figure A-1.
Interoperability with ACP 127 and civilian MHS systems is included. The access units for
Teletex and Telex are not included. The MM service provides messaging between
organizations, between persons and between persons and organizations.
9.2 Structure of Military Messages
(NU) The structure of military messages is fundamentally the same as that of IP-
messages. Additional elements in the Heading are required to support MM. In order to
support this extended message structure, military messages will form their own content
type, called P772, as shown in Figure A-2. This is distinct from the IPMS content type,
called P22.
11 SPECIALIZED ACCESS
11.1 Introduction
(NU) The MM Service includes access to ACP 127 and Civilian MHS systems. Access to
such systems is via a specialized AU, which acts as a gateway.

CIVILIAN
MHS
SERVICE
MM- USER
MM SERVICE MM-UA
Civilian-AU
MM -USER MM-UA MM-MS M-MT Service
ACP127-AU
ACP127 SERVICE
Figure A-1: [X.400|ISO 10021-1] MM Extensions

To:
From:
IPM Heading
Subject:
SIC:
MM Extended
Handling Instructions:
Heading
The rendezvous will occur

at 0800 at the location Body Part
specified on the map
below.
Body Part
Figure A-2: MM Message Structure

11.2 Teletex Access
(NU) Direct access to teletex is not within the scope of MMHS.
11.3 Telex Access
(NU) Direct access to telex is not within the scope of MMHS.
SECTION 3 – CAPABILITIES OF MHS
12 NAMING AND ADDRESSING
12.4 O/R Addresses
(NU) Military O/R Address: Provides a means of identifying originators and recipients by
organizational identity. In ACP 127 networks this is done using Plain Language Address
Designators (PLAD). Nations may choose their own addressing scheme within their
PRMD. For full interworking between MMHS and ACP 127 networks organizations must
be registered in both networks.
14 DISTRIBUTION LISTS IN MHS
14.5 DL Expansion
(NU) The DL expansion point must be trusted to regenerate or copy the security tokens
of each recipient in the DL for any environment utilizing end-to-end security services.
17 USE OF MHS IN PROVISION OF PUBLIC SERVICES
(NU) The requirements of clause 17 of X.400 do not apply to MMHS. (MMHS does not
provide a public mail service.)
SECTION 4 - ELEMENTS OF SERVICE
18 PURPOSE
(NU) This part specifies the military specific elements of service. Different military
messaging services will be built by selecting elements of service from the military
specific UA elements of service, normal ISO/IEC 10021 IPMS UA elements of service
and the MT elements of service. The selection of supported elements of service is
defined in related MMHS Profiles.
(NU) The Military Messaging Service (MMS) is one of the services. The military specific
elements of service for the MMS are described in the amendments to Annex B of [X.400
| ISO/IEC 10021-1]. They are summarized in Table 1. In this table the "ACP" column
indicates a service which is required solely to support interoperability with ACP 127
based networks.

STANAG
Specific MM Element ACP Clause
ACP 127 Message Identifier 6 B.116
ACP 127 Notification Request 6 B.118
ACP 127 Notification Response 6 B.119
Use of Address List B.104
Clear service B.112
Codress message indicator 6 B.110
Copy precedence B.102
Corrections 6 B.114
Distribution code B.107
Exempted addresses B.105
Extended authorization info (DTG) B.106
Extended grades of delivery B.100
Message instructions B.109
Message type B.103
Handling instructions 6 B.108
Originator reference B.111
Originator PLAD 6 B.117
Other recipient indicator B.113
Pilot forwarded 6 B.115
Primary precedence B.101
Table 1: Military Specific Elements of Service for MMS

ANNEXES TO [X.400 | ISO/IEC 10021-1]
EXTENSIONS TO ANNEX A – Glossary of Terms
Military Messaging Service
(NU) The Military Messaging Service (MMS) provides an electronic mail facility between
military personal and military organizational users. This service is a superset of the
commercial IPMS in which the O/R name and UA can be dedicated to either an
individual, or to an organizational post, irrespective of the identity of personnel involved.
This service is sometimes known as "Formal Messaging" or "Record Traffic".
Military Messaging User Agent
(NU) The Military Messaging User Agent (MM-UA) is the entity that represents a military
individual or organization within the MMS.
MMS Protocol
(NU) The MMS protocol supports the exchange of messages between military
individuals or organizations. The nomenclature adopted for this protocol is P772.
Military Message Transfer Service
(NU) The MMTS provides a store and forward service which supports the exchange of
military messages. It clarifies the behaviour of an MTA for military purposes.
Miscellaneous Terms
(NU) In addition to the abbreviations in the references, MMHS documentation also uses
the following abbreviations:
ACCIS Automatic Command and Control Information System

ACP Allied Communications Publications
ACCSA Allied Communications and Computer Security Agency
ADatP Allied Data Processing Publications
AL Address List
CCIS Command and Control Information System
CEN/CENELEC Joint European Standards Institution
CL Classification Word(s)
CMS Conferencing Messaging System
CMW Compartmented Mode Workstation
COMPUSEC Computer Security
COMSEC Communications Security
DES Data Encryption Standard
DTG Date Time Group
ENV European Pre-standard
MBS Military Base Standard
MLS Multi Level Secure
MM Military Message
MM- Military Messaging
MM-AU Military Messaging Access Unit
MMI Man Machine Interface


MM-MTS Military Messaging Message Transfer Service
MMS Military Messaging Service
MMTA Military Message Transfer Agent
MPDU Military Protocol Data Unit
P772 MMS protocol
PTT Public Telephone and Telegraph
SIC Subject Indicator Codes
SOTF Start of Transmission Function
SW Security Warning Operating Signal
UTC Coordinated Universal Time
Double Enveloping
(NU) Double enveloping is a technique consisting of encapsulating the content and

envelope of a message in a new outer envelope. This is done in order to protect the
information borne on the envelope whenever a message is forwarded through a less
trusted domain. The content of the new outer envelope, which is the inner envelope and
in turn the original content, may be either encrypted or not depending on the degree of
trust accorded the less trusted domain.
Plain Language Address Designator
(NU) The Plain Language Address Designator (PLAD) is defined in ACP 127 and is used
for naming organizations in ACP 127 networks.
Routing Indicator
(NU) The Routing Indicator (RI) is defined in ACP 127 and is used to define the network
address of a ComCen serving an organization or organizations. It is used for addressing
and routing purposes within ACP 127 networks.
Priority and Precedence
(NU) The term "precedence" is used in reference to any military enhanced specification
of message urgency. The terms "Primary Precedence", "Copy Precedence" are used to
denote military precedence service definitions.
Address List
(NU) An address list in MMHS is a predefined list of recipients which is expanded in the
originator's management domain.

EXTENSIONS TO ANNEX B - Definition of Elements of Service
Extended IPM services
(NU) MMS supports all of the IPMS services. MMS also supports the elements of service
that are part of the basic MT (Message Transfer) Service. These are used to transfer
military message and are available as part of the basic MM service. As part of MMS
some interpersonal services require more precise definition which are included in this
Annex.
B.37 MM-message Identification
(NU) This element of service permits co-operating MM-UAs to convey an identifier for
each message sent or received. The MMS identification provides a unique identification
of the MM-UA-message as follows:
Ÿ the O/R name of the originating MM-UA (mandatory), including the O/R address
and all components of the global domain identifier.
Ÿ a serial number generated by the organization MM-UA (mandatory).
Ÿ the filing time (the time the message generation is finished) generated by the
organization MM-UA (mandatory). This time is specified in UTC format including
seconds.
Note: the serial number and the filing time are concatenated in sequence
within the printable string of the MM-message identification, separated
by a space.
B.43 Message Security Labelling
(NU) MMS messages will carry a security label using a military policy identifier.
(NU) The clear service of ACP 127 is provided by interpretation of the values of the
security label.
(NU) The security label is composed of a formal label component and, optionally, an
information label component.
(NU) The information label can be used to record the security implications and
restrictions of handling messages. An information label policy is not defined by this
document.
B.62 Primary and Copy Recipients Indication
(NU) Primary and copy recipients correspond respectively to what is normally referred to
in ACP 127 as action and information addressee. In MMS, therefore, a primary recipient
has responsibility to act upon the delivered message, while a copy recipient has no
action responsibility and is sent the message merely for information purposes.

B.72 Reply Requested Indication
(NU) This element of service allows the originator to request a reply to a message. This
can be used to support the procedures of a military acknowledgment, which is requested
within the body of the message. Military acknowledgments is procedurally defined,
examples of which are given in ACP 121, and means that the message to which it refers
has been received and the purpose is understood by the recipient.
B.90 Typed Body
This element of service has been extended in MMHS, to support additional body part
types. The additional body part types are defined in section 7.3.12 of MMHS extensions
to [X.420|ISO/IEC 10021-7].
B.93 User/MM-UA Capabilities Registration
(NU) A user shall not be able to change registered security labels. This is a
management function.
The remaining text in Annex B summarizes the military extensions to ISO/IEC 10021:
B.101 Primary Precedence
(NU) This element of service enables an originating MM-UA to convey the military
precedence level of a message in the content header for a primary recipient. This
service is provided not only as information from originator-to-recipient, but is also used
to automatically select the MTS Grade of Delivery element of service. This service is
supported by the Miltiary Header Extension primary-precedence. The six levels of
precedence are mapped to the three levels of Grade of Delivery Military precedence is
mapped to the MTS Priority protocol element as follows.
MANDATORY
MTS
Primary
Precedence Priority
Override Urgent(2)
Flash Urgent(2)
Immediate Normal(0)
Priority Normal(0)
Routine Non-Urgent(1)
Deferred Non-Urgent(1)
(NU) Note: Additional levels of precedence may be defined for national use. Upon
receipt, the handling of unknown precedence levels will be dictated by the local handling
policy.
B.102 Copy Precedence
(NU) This element of service enables an originating MM-UA to convey the additional
precedences of a message in the heading for a copy recipient. The copy precedence
has the same range of values as the primary precedence but must assume for each
message a value equal to or lower than the primary precedence. The copy precedence
does not affect the handling of the message by the MM-MTS.

B.103 Message type
(NU) This element of service enables originating MM-UAs to distinguish messages that
relate to a specific exercise, operation , project or drill.
B.104 Use of Address List
(NU) This element of service:
Ÿ conveys the name of a pre-defined list of recipients to which the

originator has sent a message.
Ÿ specifies if the address list (AL) was sent as action or

information.
Ÿ defines if notifications or replies are required from action and/or

info recipients of the address list.
(NU) Two alternative protocol realizations may support this service: use of MMS
addressing fields for conveyance of the AL, and conveyance of the AL in the
address-list-indicator heading extension.
(NU) The members of an AL may contain pre-defined action and info recipients.
(NU) If the originator has excluded specific members of the AL from receiving
the message, then this information is conveyed in the exempted address
element of service.
(NU) The expansion of the AL will be performed by the originating MMHS

management domain, which will create an X.400 MMTS recipient for each
member of the AL not excluded, but will not create separate OR descriptors for
each member of the AL in the heading fields.
(NU) This element of service provides a service similar to AIGs and CADs in
ACP 127.
B.105 Exempted addresses
(NU) This element of service is used to convey the names of members of an AL that the
originator has specified he wants to be excluded from receiving the message. Exclusion
is provided by the originating management domain in its address list expansion. No
further processing is performed in MMHS and the element of service is information
conveying only. There is therefore no guarantee that the exempted addresses will not
receive the message as the result of redirection, DL expansion, etc.
(NU) When interfacing to ACP 127 networks, the exempted address element of service
will carry the PLADs of the excluded recipients.
B.106 Extended authorization info
(NU) This element of service consists of a Date-Time Group (DTG). Depending upon
national requirements, the DTG may indicate either the date and time when the message
was officially released by the releasing officer or the date and time when the message
was handed into a communications facility for transmission.

B.107 Distribution Code
(NU) This element of service enables the originating MM-UA to give distribution
information to a recipient MM-UA. The recipient MM-UA can use this information to
perform local distribution of a message. This service contains two components, the
Subject Indicator code (SIC) and a Distribution Code, each of which is optional. The
Distribution Code allows for future definitions of distribution criteria by either national or
allied use. Any number of codes may be specified. The assignment of the Distribution
Code can be privately defined or may be subject to future standardization. The SIC's are
published codes that provide information for message distribution after delivery to the
recipient organization.
(NU) Each SIC can consist of between 3 and 8 characters. It is possible to attach up to 8
SICs to a message.
B.108 Handling instructions
(NU) This element of service enables the originating MM-UA to indicate to the recipient
MM-UAs that local handling instructions accompany the message, and that the message
requires manual handling by a traffic operator.
(NU) Handling instructions (also called transmission instructions) are a part of format line
4 as defined in ACP 127, and concern the sending of the message, e.g. that a particular
system shall be used for transfer of the message.
B.109 Message instructions
MM-UA that message instructions accompany the message. (Message instructions are
also called remarks.) It may be used to carry operating signals specified in ACP 131 and
related national publications.
(NU) The difference between Handling instructions and Message instructions is that the
former is only for manual handling by traffic operators, while the latter also contains
information of interest to the persons reading the message.
B.110 Codress message indicator
MM-UA that the message is in codress format. The element of service applies only for
codress encrypted messages, which are restricted to a single body part.
(NU) As defined in ACP 121, "Codress is a procedure in which the entire address of a
message is encrypted within the text while the heading of any transmission of that
message contains only information necessary to enable communication personnel to
handle it properly. Codress may be implemented by a nation, service or appropriate
allied authority for use with high grade off-line cryptosystems".
B.111 Originator Reference
(NU) This service enables the originating MM-UA to indicate to a recipient MM-UA a
reference called the "originator's number". The originator's number is used by the
originating organizational unit. The originator's number differs from the MM-message
identification in that this reference is wholly supplied by the originator while the MM-
message Identification is supplied by the MM-UA.

B.112 Clear Service
(NU) This element of service indicates to the recipient MM-UA that a message
containing classified information has been transmitted over an unsecure channel, prior to
entering the security domain and may have been compromised. The service shall be
supported by using the printable string "CLEAR" in the privacy mark, together with an
appropriate security policy identifier. The fact that the message may have been
compromised shall be made available to the recipient.
(NU) The service may be used locally within the MMHS domains, when permitted by the
security policy of the security domain. In this case the message originator may submit a
message with a lower security level or without its full security protection mechanisms
being involved. In these circumstances the clear service may be supported by using a
specific security label, together with an appropriate security policy identifier.
B.113 Other recipient indicator
(NU) This element of service enables the originator to indicate to the recipient the names
of one or more recipients, as well as the category (primary or copy) in which they are
placed, that are intended to receive or have received the message via other means.
The intent of this element of service is to enable a recipient to determine which
recipients are intended to receive the message without the use of MMHS, as well as the
category in which they are placed. While the Primary and Copy Recipients Indication
and/or Address List Indicator gives the names of recipients that can be reached through
MMHS, other recipients can be determined with this element of service.
Note: This element of service gives no reason why the other recipient(s) will not
receive the message through MMHS.
(NU) Some reasons might be:
a. the recipient is not a user of the MMHS and has been sent the message
by other means;
b. the originator knows (or presumes) that a secure path to the recipient will
not be found through the MMHS and has therefore sent the message by
other means; and
c. the recipient has already received the message by other means before it
was entered in the MMHS.
B.114 Corrections
(NU) This ACP 127 element of service enables the originating MM-UA to indicate to the
recipient that there are corrections required to the text body. This service is implemented
by defining an Extended Body part of type Corrections.
B.115 Pilot forwarded
(NU) This element of service is intended for use with ACP 127 gateways and allows a
gateway to translate a pilot message. The original received "body/text" of the message
is sent as the "text body" of a new message. Pilot Information contains information which
equals or supersedes the received header information for precedence, classification,
local handling instructions and addressing.

B.116 ACP 127 Message Identifier
(NU) This element of service conveys the message identifier of an ACP 127 message in
MMHS. This consists of the RI of the originating commcen, the Station Serial Number
and the Filing Time which is conveyed in Format Line 3.
(NU) This element of service is only required to support the tandeming of ACP 127
messages through the MMHS domains.
B.117 Originator PLAD
(NU) This element of service enables the originator MM-UA to indicate to a recipient
MM-UA or ACP 127 Access Unit the plain language address, as defined in ACP 127, of
the originator of the message. Its purpose is to provide a consistent non-translated
reference across the domain types.
(NU) This element of service, together with the Extended Authorization Info element of
service, provides a cross reference for message identification in both ACP 127 and
MMHS domains.
B.118 ACP 127 Notification Request
(NU) This element of service enables the originator to request notifications from ACP
127 gateways. They can be requested for the following scenarios:
a) positive notification - the ACP 127 gateway successfully transfers the

message and accepts responsibility for its submission into the ACP 127 domain;
b) negative notification - the ACP 127 gateway has received the message, but
fails to transfer it; and
c) transfer notification - the ACP 127 gateway successfully transfers the

message but has not kept a record of the message and does not accept
responsibility for it.
B.119 ACP 127 Notification Response
(NU) This element of service conveys the results of an attempt to transfer a message
into an ACP 127 domain. It indicates whether the transfer was positive, negative, or
positive but without responsibility. It also conveys the receipt time, the ALs of the
message, the ACP 127 recipient address, and any pertinent supplementary information.

SECTION 2 – ABSTRACT MODELS
7 FUNCTIONAL MODEL
7.4 Selected AU Types
(NU) An AU is used as the interface between an MMHS and an ACP 127 system.
10 SECURITY MODEL
10.2.2.2 Security Context Security Service
(NU) The information label component of the message security label will not be used for
security context.
SECTION 4 – NAMING, ADDRESSING AND ROUTING
18 ADDRESSING
18.5 O/R Address Forms
18.5.5 MMHS O/R Address
(NU) An MMHS O/R address may contain an RI, a PLAD, or both.
(NU) An important objective of the MMHS is to provide functionality consistent with ACP
127. This has implications for MMHS addressing in that the existing ACP 127
addressing scheme based on RI's, PLAD's and address lists (address groups) must be
accommodated.
(NU) A second objective is to provide an addressing mechanism which goes beyond the
organizational level, the level supported by ACP 127, and supports direct organizational
unit or personal addressing.
(NU) A third objective is to allow inter-operability between MMHS and civilian messaging
networks. This implies that the MMHS addressing scheme must be a compatible
superset of the civilian one.
(NU) These objectives have been met with a single O/R addressing scheme.
18.5.5.1 MMHS OR-Addressing
(NU) The main idea behind the MMHS addressing scheme is to use only the standard
attribute list as defined in the base standard as routing attributes within the MTS.
(NU) The appropriate Military Registration Authorities will register MMHS O/R Names,
which may be based on existing PLADs and RIs, or any other address information, such
as staff cell name, role name or staff title.

(NU) Existing military names and addresses for message handling defined in the ACP
publication (i.e. PLAD's and RI's) can be conveyed intact within the military domain
defined attributes of the O/R Address.
Standard Attribute List
Military Domain Defined Attribute List

RI "acp-ri"
PLAD "acp-plad"

2 References
ACP 121 Transmission Instructions

ACP 127 Message Relay Procedures
SECTION 2 – MESSAGE TRANSFER SYSTEM ABSTRACT SERVICE
8 Message Transfer System Abstract Service Definition
8.2 Submission Port
8.2.1 Abstract Operations
8.2.1.1 Message Submission
8.2.1.1.1 Arguments
8.2.1.1.1.8 Priority
(NU) Military Precedence should be mapped on to the civilian message priority in the
following manner.
Military Precedence Civilian Priority

Deferred Non-Urgent
Routine Non-Urgent
Priority Normal
Immediate Normal
Flash Urgent
Override Urgent
8.2.1.1.1.30 Message-security-label
(NU) In order to support the Clear Service, the message security label shall assume
particular values. The main purpose of the Clear Service is to convey the CLEAR
security classification from messages arriving from ACP 127 domains. In that case the
privacy mark will have a value of printable string "CLEAR", together with an appropriate
security policy identifier.
(NU) Use of the Clear Service as a means of tandeming messages through untrusted
domains or over an unprotected link is strongly discouraged. Double enveloping should
be used instead. The Clear Service may be invoked only under the appropriate
procedures defined by the security policy of the domain. No originator selection of "clear
service permitted" is defined or required.
8.2.1.1.1.34 Content-type
(NU) This Annex identifies the following additional content types:
(NU) Military-messaging-1988: identifies the military-messaging-1988 content-type

defined in the MMHS extensions to [X.420 | ISO/IEC 10021-7].

8.2.1.4 Submission Control
8.2.1.4.1 Arguments
8.2.1.4.1.2 Permissable Operations
(NU) The MMTS should tell the MMTS user that submission of probes is prohibited.
9.0 Message transfer system abstract syntax definition
-- OR Names
-- Domain-defined attributes

RI "acp-ri"
PLAD "acp-plad"
-- others to be defined
-- Military OBJECTS
-- Security Categories
atomal SECURITY-CATEGORY
::= id-nato-mmhs-cat-atomal
cryptoSecurity SECURITY-CATEGORY
::= id-nato-mmhs-cat-cryptosecurity
specialHandlingIntel SECURITY-CATEGORY
::= id-nato-mmhs-cat-specialhandlingintel
usSIOPesi SECURITY-CATEGORY
::= id-nato-mmhs-cat-usiopesi
eyesOnly SECURITY-CATEGORY
::= id-nato-mmhs-cat-eyesonly
exclusive SECURITY-CATEGORY
::= id-nato-mmhs-cat-exclusive
securityInformationLabel SECURITY-CATEGORY
SecurityLabel
::= id-nato-mmhs-cat-information-label
-- cannot itself have an information label as
-- a category (i.e. only one level of nesting)
SECTION 3 – MESSAGE TRANSFER AGENT ABSTRACT SERVICE
12 Message Transfer Agent Abstract Service Definition
12.2 Transfer Port
12.2.1 Abstract Operations
12.2.1.1 Message Transfer
(NU) When relaying, all attributes in an OR Address should be relayed. Specifically, all
occurrences of Domain Defined Attributes shall be relayed. Domain Defined Attributes
are not used for interdomain routing.

12.2.1.2 Probe Transfer
(NU) Submission of probes is not permitted, nor is transfer of probes via gateways to
other networks. They should not occur in the MMTS.The occurrence of probes shall be
audited.
SECTION 4 – PROCEDURES FOR DISTRIBUTED OPERATION OF THE MTS
14 Procedures for Distributed Operation of the MTS
14.3 Main Module
14.3.10 Distribution List Expansion Procedure
(NU) DL owners should be able to optionally request delivery/non-delivery reports for all
the DL's members.
14.4 Report Module
14.4.3 Report Generation Procedure
(NU) When copying an ORName of an incoming message into a DeliveryReportMPDU

(e.g. the originator of the original message), all attributes (also UNSUPPORTED
attributes) should be copied.

ANNEX A – Reference Definition of MTS Object Identifiers
id-nato-mmhs-cont-mm84 OBJECT IDENTIFIER

::= {id-mcont 0}
id-nato-mmhs-cont-mm88 OBJECT IDENTIFIER

::= {id-mcont 1}
id-policy-nato OBJECT IDENTIFIER

::= {id-policy 0}
-- NOTE: the parameters of security categories have not yet been defined, but
-- may be used to carry Special Handling Markings
id-nato-mmhs-cat-atomal OBJECT IDENTIFIER

::= {id-cat 1}
id-nato-mmhs-cat-cryptosecurity OBJECT IDENTIFIER

::= {id-cat 2}
id-nato-mmhs-cat-specialhandlingintel OBJECT IDENTIFIER

::= {id-cat 3}
id-nato-mmhs-cat-ussiopesi OBJECT IDENTIFIER

::= {id-cat 4}
id-nato-mmhs-cat-eyesonly OBJECT IDENTIFIER

::= {id-cat 5}
id-nato-mmhs-cat-exclusive OBJECT IDENTIFIER

::= {id-cat 6}
id-nato-mmhs-cat-information-label OBJECT IDENTIFIER

::= {id-cat 7}
ANNEX D - Conformance
Dynamic conformance statements
(NU) The "priority" element of the PDUs is dynamically mandatory.

SECTION 2 - MESSAGE STORE ABSTRACT SERVICE DEFINITION
6 MESSAGE STORE MODEL
6.4 Stored-messages
(NU) c) Processed - means that the MM-UA has "completely fetched" the message and
made the contents available to the user. Auto-actions which would result in the message
being deleted are prohibited.

MMHS EXTENSIONS FOR P772 PROTOCOL
The Military Messaging Service (MMS) is a new service which is based on the
Interpersonal Messaging Service (IPMS) specification, defined by the CCITT X.420
Recommendation and International Standard ISO/IEC 10021-7.
1 SCOPE
(NU) The specification of the Military Messaging Service (MMS) is defined as a delta
from the civilian Interpersonal Messaging Service (IPMS). When reading the civilian
standard [X.420 | ISO/IEC 10021/7] which forms the baseline, the reader should
therefore substitute "MMS" for "IPMS".
2 REFERENCES
(NU) See MMHS Extensions to [X.400 | ISO/IEC 10021-1]
3 DEFINITIONS
4 ABBREVIATIONS
SECTION 2 – ABSTRACT INFORMATION OBJECTS
7 MILITARY MESSAGES
7.1 Heading Field Component Types
7.1.1 MM Identifier
NOTE: The IPMIdentifier protocol element shall be used in respect

of mandatory support in order to achieve the global Military
Message identification requirement.
NOTE: The O/R Name of the originating MM-UA shall include the O/R
Address and all components of the global domain identifier.
user - the O/R name of the originating MM-UA (mandatory),

including all components of the global domain
identifier
LocalIPMIdentifier - a serial number generated by the

originating MM-UA (mandatory)
the filing time (the time the message

generation is finished) generated by the
originating MM–UA (mandatory). This time
is specified in UTC format including
seconds.

Note: the serial number and the filing time are concatenated
in sequence within the printable string of the IP-
message identification, separated by a space.
7.1.2 Recipient Specifier
(NU) A given recipient may be reachable only via a gateway between MMHS and ACP
127 domains. A per-recipient extension has been defined to permit the originator to
request that if such a gateway is encountered then it should generate a notification
identifying the level of success in translating the message. A description of these levels
is provided in Section 8.4. The detailed specification is provided in Annex A. It makes
use of the recipient-extensions component of the RecipientSpecifier.
7.2 Heading Fields
7.2.17 Extensions
(NU) Header extensions for MMHS are defined in ANNEX A. Nations may define
additional header extensions for private use. Support of Nationally defined header
extensions across National boundaries are subject to bilateral agreements. Unsupported
header extensions may be ignored by an MM-UA on reception.
7.3 Body Part Types
7.3.8 Message
(NU) A message body represents an IPM body. If security is used then its delivery
envelope is included in the body part.
(NU) An MM-UA can forward an MM-message in the MM-message body part and/or an
IPM message using the message body part.
7.3.12 Externally Defined
(NU) Externally defined body part types for MMHS are listed in ANNEX B. They include
body part types:
1) ADatP3;
2) Corrections;
3) Forwarded-Encrypted;
4) MM-Message; and
5) ACP127Data.
7.3.12.1 ADatP3
(NU) The ADatP3 body part will be used to convey military ADatP3 messages or
sometimes refered to as proforma messages.
(NU) The text in the ADatP-3 body part can be delimited by carriage return/line feed or
can be set oriented. The ADatP-3 body part also includes the message index reference
number for identification of the ADatP-3 message type.
7.3.12.2 Corrections
(NU) Corrections body part will be used to convey corrections to a message, which
maybe conveyed in another body part type.

7.3.12.3 Forwarded Encrypted
(NU) The forwarded encrypted body part will be used to convey a message that has
been forwarded by an MM-UA. The forwarded encrypted body part will contain the
original encrypted content type and envelope information.
Note, this functionality is also applicable to an MM-MS and an MM-AU.
7.3.12.4 MM-Message
(NU) The MM-Message body part will be used to convey a Military Message that has
been forwarded by an MM-UA. The MM-Message body part will contain the original
contents. In the case of an encrypted message, the message will be decrypted prior to
forwarding the message.
Note, this functionality is also applicable to an MM-MS and an MM-AU.
7.3.12.5 ACP127Data
(NU) The ACP127Data body part will be used to convey ACP 127 data pattern traffic.
8 MILITARY NOTIFICATIONS
8.4 Other Notification Type Fields
Three types of notifications have been defined in order to provide information to the
originator about a message which encounters an MMHS/ACP 127 gateway:
1. A positive ACP 127 notification indicates that a gateway has successfully

translated a military message into ACP 127 and takes communications
responsibility for its trace and recovery.
2. A negative ACP 127 notification indicates that a gateway has failed to translate a
military message to ACP 127 and does not take communications responsibility
for its trace and recovery.
3. A transfer ACP 127 notification indicates that a gateway has successfully
translated a military message to ACP 127 but does not take communications
responsibility for its trace and recovery.
Any or all of these notifications may be requested by the originator using an ACP 127
notification request. The detailed ASN.1 specification is provided in Annex A.
SECTION 3 – ABSTRACT SERVICE DEFINITION
12 ABSTRACT OPERATIONS
12.1 Origination Abstract Operations
12.1.1 Originate Probe
(NU) MM-UA's shall not be allowed to submit probes.

12.1.2 Originate MM
(NU) Both X.400 distribution lists (DLs) and Address Lists (ALs) will be supported by
MMHS. DL expansion and management will be performed by the MTS as described in
the civil standards. The expansion of an AL, tailored by the exempted address list, will
be performed by the originating management domain.
12.3.3 Change Auto-forwarding
The change auto-forwarding abstract operation enables or disables auto-forwarding, the

automatic forwarding of MMs by the MM-MS to pre-specified users or DLs. Such
forwarding occurs upon delivery of the MMs.
ChangeAutoForwarding ::= ABSTRACT-OPERATION

ARGUMENT SET {
auto-forward-IPMs BOOLEAN,
auto-forward-recipients SEQUENCE OF ORName OPTIONAL,
auto-forward-heading Heading OPTIONAL,
auto-forward-comment AutoForwardComment OPTIONAL }
RESULT
ERRORS {
SubscriptionError,
RecipientImproperlySpecified }
Note: The auto-forward-IPM structure is used to inidcate auto-forward-MM.
The body of each MM the MM-MS originates as a result of auto-forwarding comprises a

single body part of type mm-message or forwarded-encrypted. The content of the
message represented by that body part is the forwarded MM.
Note: For implementations which support dual MM and IPM functionality, the single body
part within the body can also be of type message. In this case, the content of the
message represented by that body part is a forwarded IPM.
When it auto-forwards a message, the MM-UA originates an NRN on the user’s behalf if,
and only if, one was requested of him by means of the notification-requests component
of the subject recipient specifier.
This abstract operation has the following arguments:
a) auto-forward-IPMS (M): Whether or not MMs are to be auto-forwarded. A

Boolean.
b) auto-forward-recipients (C): The users or DLs to which MMs are to be auto-
forwarded. A sequence of O/R names.
This conditional argument shall be present if, and only if, the auto-forward-
IPMs argument has the value true.
c) auto-forward-heading (C): The heading that is to be used for each forwarding
IPM. Its auto-forwarded heading field shall have the value true.
This conditional argument shall be present if, and only if, the autoforward-
d) auto-forward-comment (C): The value that is to be supplied as the auto-
forward comment non-receipt field of each NRN conveyed to the originator
of an auto-forwarded IPM.
This conditional argument shall be present if, and only if, the autoforward-

This abstract operation has no results.
Note: This abstract operation is intended to define the essence of auto-forwarding,

sophisticated auto-forwarding capabilities, e.g., like those of an MS.
Note: For implementations which support dual MM and IPM functionality, the arguments
above may apply to both MMs and IPMs.
SECTION 4 – ABSTRACT SERVICE PROVISION
16 SECONDARY OBJECT TYPES
16.6 Message Transfer System
(NU) The gateways to ACP 127 and Civilian MHS domains are both access units (AU).
18 USER AGENT OPERATION
NOTES:
(NU) ALs support the Exempted Addresses capability in an MMHS domain.
18.2 Performance of Origination Operations
18.2.1 Originate Probe
(NU) MM-UA's shall not be allowed to submit probes.
18.2.2 Originate MM
(NU) Both X.400 DL's and AL's will be supported by MMHS. DL expansion and
management will be performed by the MTS as described in the civil standards. The
expansion of an AL, tailored by the exempted address list, will be performed by the
originating management domain. In MMHS, only AL's will support the Exempted
Addressees capability.
The setting of the message submission fields for each recipient shall either:
(1) defaulted to a configurable set; or

(2) user selectable.
18.5.3.1 Prevention of Loops
The UA shall suppress auto-forwarding if, and only if, the MM to be forward itself
contains a forwarding MM that the UA created. Autoforwarding shall be suppressed
whether the forwarding MM appears (directly) in wither a MM-message or a Forwarded-
encrypted body parts of the MM to be forwarded, or (nested) in the body parts of the MM
that appears in such body parts.
Note: For implementations which support dual MM and IPM functionality, the above
mentioned conditions also apply to forwarded MMs which include Message bodies
containing IPMs.
The UA shall consider itself to have created the forwarding MM above (whose Auto-
forwarded heading fields has the value true) if, and only if, the originator-name
component of the MM’s Parameter component matches the O/R name of the UA.

Note: Auto-forwarding an MM of the kind above constitutes an Auto-forwarding loop.
18.5.3.2 Construction of MM
The UA shall construct a forwarded MM whose Heading is the Auto-forwarded-heading

state variable (it’s Auto-forwarded filed having the value true) and whose body comprises
a single body part, which can be either of type:
a) Forwarded-Encrypted: This body part type will be used if, and only if, the
received message (either an MM or an IPM) is encrypted and the UA is
enable to decrypt the message prior to forwarding. The entire original
encrypted message will be conveyed in the forwarded-encrypted body part.
b) MM-Message: This body part type will be used if, and only if, the received
message is an MM and the condition described in a) above does not apply
(i.e., the MM is not encrypted or has been decrypted) prior to forwarding the
message.
Two body part types used for message forwarding shall have the following components:
a) Parameters: The envelope argument of message delivery.

b) Data: The message (either MM or IPM) to be forwarded.
Note: For implementations which support dual MM and IPM functionality, possible it is
also possible to use the message body part type. It may be used to convey (a)
messages received as IPMs and (b) messages received as MMs but downgraded to an
IPM by any UA with capabilities to do it. Encrypted IPMs that cannot be decrypted by
the UA prior to forwarding may be forwarded within a Forwarded-Encrypted body part
type.
18.5.3.4 Construction of NRN
The following note shall be appended to clause 18.5.3.4 in X.420:
Note: This is applicable for both forwarded MMs and IPMs.
19 MESSAGE STORE OPERATION
19.2 Maintenance of Attributes
(NU) "Processed" means that the MM-UA has completely fetched the message and
made the message contents available to the user.
19.4 Auto-forwarding
The following note shall be appended to clause 19.4 in X.420:
Note: The requirements are also applicable to an MS implementation which performs

Autoforwarding of IPMs.

19.5 Manual Forwarding
An MM-MS shall support the manual forwarding of a message, using the forwarding-
request extension of recommendation [X.413 | ISO/IEC 10021-5]. The MM-MS user
may submit an MM, including heading and body, using the message submission
operation and identify by using the forwarding request extension, a message in the MS
which needs to be forwarded.
The MS will construct a forwarded message using the following body part type:
a) Forwarded-Encrypted: This body part type will be used if, and only if, the
received message (either an MM or an IPM) is encrypted and the UA is
enable to decrypt the message prior to forwarding. The entire original
encrypted message will be conveyed in the forwarded-encrypted body part.
b) MM-Message: This body part type will be used if, and only if, the received
message is an MM and the condition described in a) above does not apply
(i.e., the MM is not encrypted or has been decrypted) prior to forwarding the
message.
The submitted message and the message to be forwarded are then combined by
inserting the appropriate body part type into the submitted message.
Note: For implementations which support dual MM and IPM functionality, possible it is
also possible to use the message body part type to forward a message. This may be
used whenever (a) the message to be forwarded is an IPM or (b) the message is an MM,
but the UA has the capability to downgrade it into an IPM. Encrypted IPMs that cannot
be decrypted by the UA prior to forwarding may be forwarded within the Forwarded-
Encrypted body part type.
20 MESSAGE CONTENTS
20.2 Content Type
(NU) Military messaging will use a content type denoted by the object identifier id-nato-
mmhs-cont-mm88. The protocol used for military messaging is called P772.
22 CONFORMANCE
The requirements a secondary object (excluding the MTS) and its implementor shall
meet when the later claims conformance to this MM Recommendation are identified
below. The requirements listed below supersede the requirements listed in clause 22.1 -
22.4 of Fascicle VIII.7 - Rec. X.420.
22.1 Origination versus reception
A MM-UA or AU shall be said to support upon origination a particular heading field,

heading extension, basic body part type, or extended body part type, if and only if, it
accepts, preserves and emits, in full accord, with this STANAG, that particular heading
field or extension, or body parts of that particular basic or extended types, whenever, a
user calls upon it to convey an MM containing them to the MTS or the user’s MM-MS
(the later only in the case of a MM-UA).

A MM-UA, or AU shall be said to support upon reception a particular heading field,

heading extension, basic body part type or extended body part type, if any only if, it
accepts, preserves and emits, in full accord with this STANAG, that particular basic or
extended type, whenever, the MTS or user’s MM-MS (the later only in the case of a MM-
UA) calls upon it to convey to the user an MM containing them.
22.2 Statement requirements
The implementor of a MM-UA, MM-MS, or AU shall state the following. For each item
below, he shall make separate statements concerning conformance upon origination and
conformance upon reception:
a) The heading fields and extensions for which he claims conformance.

b) The basic and extended body parts for which he claims conformance.
c) In the case of an MM-MS or MM-UA accessing an MM-MS, the Military-
Messaging-specific MS attribute-types for which conformance is claimed.
d) In the case of an MM-MS or MM-UA accessing and MM-MS, any claim of
conformance for the auto-forward, auto-action defined in [Rec
X.413/ISO/IEC 10021-5].
22.3 Static requirements
A MM-UA, MM-MS, or AU shall satisfy the following static requirements:
a) A MM-UA, MM-MS, or AU shall implement the heading fields and heading

extensions, and the basic and extended body parts for which conformance is
claimed.
b) A MM-MS or MM-UA accessing a MM-MS shall support the Military
Messaging-specific MS attribute-types for which conformance is claimed.
Including as a minimum those attributes-types designated as mandatory in
Annex C.
c) A MM-UA, MM-MS, or AU shall concretely realize its abstract ports as
specified in Clause 21 of [Rec X.420/ISO/IEC 10021-7].
d) A MM-UA or MM-MS shall be able to submit and accept delivery Military
Messages of the content type specified by the object identifier id-nato-
mmhs-cont-mm88.
22.4 Dynamic Requirements
A MM-UA, MM-MS, or AU shall satisfy the following dynamic requirements:
a) A MM-UA or MM-MS shall follow the rules of operation specified in Clause

18 of [Rec X.420/ISO/IEC 10021-7] or Clause 19 of [Rec X.420/ISO/IEC
10021-5] respectively.
b) A MM-UA, MM-MS, or AU shall submit and accept delivery of Military
Messages of the content-type specified by the object identifier id-nato-
mmhs-cont-mm88.
c) A MM-UA, MM-MS, or AU shall register with the MTS its ability to accept
delivery of Military Messages of the content specified by the object identifier
id-nato-mmhs-cont-mm88, as well as, any message of the other two content
types specified in Clause 20.2 of [Rec X.420/ISO/IEC 10021-7].
d) The Primary Precedence shall be mapped onto the grade of delivery
abstract service (and extended grade of delivery if that option is selected by
the profile in question).

The following annexes are additionnal to annex A to X.420. All extentions defined in
Annex A of X.420 are also applicable fo MM messaging.
ANNEX A1 - Military Heading Extensions
This annex contains definitions of military heading extensions which are defined using
the IPMS-EXTENSION macro.
Note, all lower bounds and upper bounds used in this section are defined in Annex K of
this part of the MBS.
A1.1 Exempted address
The exempted address heading extension, by its presence indicates the names of
members in an Address List that should not receive the message.
exempted-address IPMS-EXTENSION
VALUE SEQUENCE OF ExemptedAddress
::= id-nato-mmhs-mm-exempted-address
ExemptedAddress ::= ORDescriptor

-- O/R Descriptor, as defined in 7.1.3 of ITU X.420
If this extension is absent from the Extensions heading field, all members of an AL will
be considered to be valid recipients of the message.
A1.2 Extended authorisation information
The extended authorisation info heading extension, by its presence indicates either the
date and the time when the message was officially released by the releasing officer or
the date and time when the message was handled by a communication facility for
transmission.
extended-authorisation-info IPMS-EXTENSION
VALUE ExtendedAuthorisationInfo
::= id-nato-mmhs-mm-extended-authorisation-info
ExtendedAuthorisationInfo ::= UTCTime

-- UTCTime as defined in 8.5.4 of ITU X.411
The originating message domain shall ensure that the extended-authorization-info

extension is always present in the message.
A1.3 Distribution codes
The distribution codes heading extension, by its presence indicates distribution

information to a recipient or a recipient's MM-UA. This information can be used to
perform automatic or manual local distribution of a message.
distribution-codes IPMS-EXTENSION
VALUE DistributionCodes
::= id-nato-mmhs-mm-distribution-codes

DistributionCodes ::= SET {

sics [0] SEQUENCE SIZE
(1..ub-military-number-of-sics)
OF Sic OPTIONAL,
dist-Extensions [1] SEQUENCE OF DistributionExtensionField
OPTIONAL}
Sic ::= PrintableString (SIZE (lb-military-sic..ub-military-sic))
DistributionExtensionField ::= SEQUENCE {

dist-type OBJECT IDENTIFIER,
dist-value ANY DEFINED BY dist-type}
If this extension is absent, then the local distribution will be in accordance with the
message handling policy of the recipient's domain.
A1.4 Handling instructions
This is a transitional heading extension, used when interoperating with ACP 127
domains.
The handling instructions heading extension, by its presence indicates local handling
instructions that may require some manual handling by a traffic operator.
handling-instructions IPMS-EXTENSION
VALUE HandlingInstructions
::= id-nato-mmhs-mm-handling-instructions
HandlingInstructions ::= SEQUENCE OF MilitaryString
MilitaryString ::= PrintableString (SIZE(1..ub-military-string))
If this extension is absent the message will be considered as not requiring manual
handling by a traffic operator.
A1.5 Message instructions
The message instructions heading extension, by its presence indicates message

instructions accompaning the message (e.g., similar to the operating signals specified in
ACP 131).
message-instructions IPMS-EXTENSION
VALUE MessageInstructions
::= id-nato-mmhs-mm-message-instructions
MessageInstructions ::= SEQUENCE OF MilitaryString

-- MilitaryString as defined in A1.4
If this extension is absent the message will be considered received without message instructions.
A1.6 Codress message
domains.

The codress message heading extension, by its presence indicates that the message is
in codress format.
codress-message IPMS-EXTENSION
VALUE CodressMessage
::= id-nato-mmhs-mm-codress-message
CodressMessage ::= INTEGER
If this extension is absent the message will be considered received without the codress
format.
A1.7 Originator reference
The originator reference heading extension, by its presence indicates a user defined
reference called the originator’s number.
originator-reference IPMS-EXTENSION
VALUE OriginatorReference
::= id-nato-mmhs-mm-originator-reference
OriginatorReference ::= MilitaryString

If this extension is absent, then the message will be considered received without any
user defined reference.
A1.8 Primary precedence
The primary precedence heading extension, by its presence indicates the precedence
level of the primary recipients.
primary-precedence IPMS-EXTENSION
VALUE MMHSPrecedence
::= id-nato-mmhs-mm-primary-precedence
MMHSPrecedence ::= INTEGER {deferred (0), routine (1),

priority (2), immediate (3), flash (4), override (5)}
-- Note: Values 0 to 15 are reserved for NATO defined precedence

-- levels. Values 16 to 31 are reserved for national user.
The message originating domain shall ensure that this extension is always present for
action addressees.
A1.9 Copy precedence
The copy precedence heading extension, by its presence indicates the precedence level
of the copy recipients.
copy-precedence IPMS-EXTENSION
VALUE MMHSPrecedence -- MMHSPrecedence as defined in A1.8
::= id-nato-mmhs-mm-copy-precedence

-- Note: Values 0 to 15 are reserved for NATO defined precedence

-- levels. Values 16 to 31 are reserved for national user.
The message originating domain shall ensure that this extension is present for all
information addressees.
A1.10 Message type
The message type heading extension, by its presence indicates whether the message is
to be considered as an exercise, an operation, a projet or a drill.
message-type IPMS-EXTENSION
VALUE MessageType
::=id-nato-mmhs-mm-message-type
MessageType ::= SET{

type [0] TypeMessage,
identifier [1] MessageIdentifier OPTIONAL}
TypeMessage ::= INTEGER {exercise(0), operation(1), project(2),

drill(3)}
-- Note: Values 0 to 127 are reserved for NATO defined

-- Message Type identifiers. Values above 128 to 255 are not
-- defined by NATO and may be used nationally or bilaterally.
MessageIdentifier ::= MilitaryString

-- MilitaryString as defined by A1.4
If this extension is absent the message will be considered to be an undefined typed.
A1.11 Address list indicator
The address list indicator heading extension, by its presence indicates the names of
predefined list of recipients. In addition, it specifies the precedence level of each list and
whether a notification or a reply has been requested.
address-list-indicator IPMS-EXTENSION
VALUE SEQUENCE OF AddressListDesignator
::=id-nato-mmhs-mm-address-list-indicator
AddressListDesignator ::=SET {
type [0] INTEGER {primaryAddressList (0),
copyAddressList (1)},
listName [1] ORDescriptor,
-- O/R Descriptor as defined in 7.1.3 of ITU X.420
notificationRequest [2] AddressListRequest OPTIONAL,
replyRequest [3] AddressListRequest OPTIONAL}
AddressListRequest ::= INTEGER {action(0), info(1), both(2)}

If this extension is absent, the message will be considered as one that does not have an
associated address list.
A1.12 Other recipients indicator
The other recipients indicator heading extension, by its presence indicates the names of
recipients, as well as the category (primary or copy) in which they are placed, that are
intended to receive or have received the message via means other than MMHS.
other-recipients-indicator IPMS-EXTENSION
VALUE SEQUENCE OF OtherRecipientDesignator
::=id-nato-mmhs-mm-other-recipients-indicator
OtherRecipientDesignator ::= SET {

type [0] INTEGER {primary(0), copy(1)},
designator [1] MilitaryString}
The absence of this element does not guarantee that all recipients are within the MMHS.
A1.13 Pilot forwarding information
domains.
The pilot forwarding info heading extension, by its presence indicates ACP127 related
useful information, which equals or supersedes the received header information for
precedence, classification, local handling instruction and addressing.
pilot-forwarding-info IPMS-EXTENSION
VALUE SEQUENCE OF PilotInformation
::= id-nato-mmhs-mm-pilot-forwarding-info
PilotInformation ::= SEQUENCE {

pilotPrecedence [0] MMHSPrecedence OPTIONAL,
-- MMHSPrecedence as defined in A1.8
-- Note: Values 0 to 15 are reserved for NATO defined

-- precedence levels. Values 16 to 31 are reserved for
-- national use.
pilotRecipient [1] SEQUENCE OF ORDescriptor OPTIONAL,

-- O/R Descriptor as defined in 7.1.3 of ITU X.420
pilotSecurity [2] MessageSecurityLabel OPTIONAL,
-- MessageSecurityLabel as defined in 8.5.9 of ITU X.411
pilotHandling [3] SEQUENCE OF MilitaryString OPTIONAL}
-- MilitaryString as defined by A1.4
If this extension is absent, the message will be considered as one that does not contain
any pilot information.

A1.14 ACP127 message identifier
domains.
The ACP127 message identifier heading extension, by its presence indicates an ACP
127 message identifier which originated from an ACP 127 domain.
acp127-message-identifier IPMS-EXTENSION
VALUE Acp127MessageIdentifier
::= id-nato-mmhs-mm-acp127-message-identifier
Acp127MessageIdentifier ::= MilitaryString

-- as defined in A1.4
If this extension is absent, then the message did not encounter an ACP 127 domain.
A1.15 Originator PLAD
domains.
The originator plad heading extension, by its presence indicates the plain language
address associated with an originator for cross reference purposes.
-- string to store routing indicator, station serial number and

-- julian file time, separated by spaces
originator-plad IPMS-EXTENSION
VALUE OriginatorPlad
::= id-nato-mmhs-mm-originator-plad
OriginatorPlad ::= MilitaryString

If this extension is absent, then the message will be considered to not having an
originators PLAD cross reference between the MMHS and ACP 127 domains.

ANNEX A2 - Military per Recipient Specifier Extensions
This annex contains definitions of military per recipient specifier extensions which are
defined using the IPMS-EXTENSION macro.
A2.1 ACP127 notification request
The ACP127 notification request per recipient specifier extension, by its presence
indicates the type of notification requested from an ACP127 gateway.
-- The following definitions are made in order to support

-- informing the originator of a message that the subject message
-- has reached a gateway to an ACP 127 domain.
acp127-notification-request IPMS-EXTENSION
VALUE Acp127NotificationType
::= id-nato-mmhs-mm-acp127-notification-request
Acp127NotificationType ::= BIT STRING {

acp127-nn (0), -- negative notification
acp127-pn (1), -- positive notification
acp127-tn (2)} -- transfer notification
An MM-UA on receiving the request may ignore the extension.

ANNEX A3 - Military OtherNotificationTypeField Extensions
This annex contains definitions of military notification extensions which are defined using
the IPMS-EXTENSION macro.
A3.1 ACP127 notification response
The extension is only generated by ACP127 gateways.
The ACP127 notification response notification extension, by its presence indicates the
result of an attempt to transfer a message into an ACP127 domain.
acp127-notification-response IPMS-EXTENSION
VALUE Acp127NotificationResponse
::= id-nato-mmhs-mm-acp127-notification-response
Acp127NotificationResponse ::= SET {

acp127-notification-type [0] Acp127NotificationType,
receipt-time [1] ReceiptTimeField,
-- ReceiptTimeField as defined in 8.3.1 of ITU X.420
addressListInicator [2] AddressListIndicator OPTIONAL,
acp127-recipient [3] Acp127Recipient OPTIONAL,
acp127-supp-info [4] Acp127SuppInfo OPTIONAL}
AddressListIndicator ::= SEQUENCE OF AddressListDesignator

-- AddressListDesignator as defined in A1.11
Acp127Recipient ::= PrintableString (SIZE

(1..ub-military-bigstring))
Acp127SuppInfo ::= PrintableString (SIZE

(1..ub-military-bigstring))

ANNEX B - Extended Body Part Types
The following extended body parts are defined in addition to those extended body parts
defined in Annex B of X.420.
B1 Military extended body part types
B1.1 ADatP3
(NU) An Adatp3 body part represents an information object, which is used to convey
military ADatP3 messages. It has Parameters and Data components.
adatp3-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS ADatP3Parameters IDENTIFIED BY
id-nato-mmhs-et-adatp3-parameters
DATA ADatP3Data
::= id-nato-mmhs-et-adatp3
ADatP3Parameters ::= INTEGER DEFAULT (0)
ADatP3Data ::= CHOICE{

lineOriented [0] IMPLICIT IA5String,
setOriented [1] IMPLICIT SEQUENCE OF IA5String}
B1.2 Corrections
(NU) A correction body part represents an information object, which is used to convey
corrections to information in another body part. The corrections body part is only used
when interoperating with ACP 127 domains. It has Parameters and Data components.
corrections-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS CorrectionsParameters IDENTIFIED BY
id-nato-mmhs-et-corrections-parameters
DATA CorrectionsData
::= id-nato-mmhs-et-corrections
CorrectionsParameters ::= INTEGER
CorrectionsData ::= IA5String
B1.3 Forwarded encrypted
(NU) A forwarded encrypted body part represents an information object, which is used to
convey information about an encrypted message which has been forwarded prior to any
decryption having taken place. It has Parameters and Data components.
forwarded-encrypted-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS ForwardedEncryptedParameters IDENTIFIED BY
id-nato-mmhs-et-forwarded-encrypted-parameters
DATA ForwardedEncryptedData
::= id-nato-mmhs-et-forwarded-encrypted

-- A forwarded-encrypted-body must contain the delivery

-- information, containing the content type which will indicate
-- whether the forwarded encrypted message is an MM or IPM. All
-- security related information (i.e., token) of the original
-- message must be forwarded.
ForwardedEncryptedParameters ::= SET {

delivery-time [0] MessageDeliveryTime OPTIONAL,
-- MessageDeliveryTime as defined in Figure 2/X.411,
-- Part 11 of 26.
delivery-envelope [1] OtherMessageDeliveryFields}
-- OtherMessageDeliveryFields as defined in
-- Figure 2/X.411, part 9 of 26.
ForwardedEncryptedData ::= BIT STRING
B1.4 MM message
(NU) A MM message body part represents an information object that is used to convey a
forwarded message which is not encrypted. It has Parameters and Data components.
mm-message-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS MMMessageParameters IDENTIFIED BY
id-nato-mmhs-et-mm-message-parameters
DATA MMMessageData
::= id-nato-mmhs-et-mm-message
-- An mm-message-body-part can either carry a forwarded MM or a

-- forwared IPM. In the case of a message-body-part, as defined in
-- X.420, it can only carry an IPM.
MMMessageParameters ::= SET {

-- MessageDeliveryTime as defined in
-- Figure 2/X.411, Part 11 of 26.
-- OtherMessageDeliveryFields as defined
-- in Figure 2/X.411, part 9 of 26.
MMMessageData ::= MM

B1.5 ACP127DATA
(NU) An ACP127DATA body part represents an information object, which is used to

convey data pattern traffic. The ACP127DATA body part is only used when
interoperating with ACP 127 domains. It has Parameters and Data components.
acp127data-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS ACP127DataParameters IDENTIFIED BY
id-nato-mmhs-et-acp127data-parameters
DATA ACP127DataData
::= id-nato-mmhs-et-acp127data
ACP127DataParameters ::= INTEGER
ACP127DataData ::= IA5String (SIZE(1..ub-data-size))

ANNEX C - Message Store Attributes
The following definitions of MS attributes are in addition to those specified in Annex C of

X.420.
It should be noted that names of attributes which contain the term "IPM", defined in
Annex C of X.420, should be read as the term "MM". For example, "ipm-entry-type
should be read as "mm-entry-type". Note, the object identifiers for ipm and mm attributes
will remain identical, as defined by the civil X.420 standards.
Table C-3 [X.420 | ISO/IEC 10021-7]
Summary of MS Attributes
Attribute V L MM LA S
A
ACP 127 Message Identifier S O C N N
ACP 127 Notification Request S O C Y Y
ACP 127 Notification Response S O C Y Y
Address List Designator M O C Y Y
C
Codress Message S O C Y Y
Copy Precedence S O C Y N
D
Distribution Codes S O C Y N
Distribution Extensions M O C Y* Y*
E
Exempted Addresses M O C Y N
Extended Authorization Info S O C N N
H
Handling Instructions S O C Y Y
M
Message Type S O C Y N
Message Instructions S O C Y N
O
Other Recipients Designator M O C Y Y
Originator Reference S O C Y Y
Originator PLAD S O C N N
P
Primary Precedence S O C Y Y
Pilot Information M O C Y Y
S
SIC Codes M O C Y Y
* = The dist-value field shall be disregarded for the purpose of matching, unless
the syntax of the field is recognized based on the values of the dist-type field.

C.2.5 Military Heading Extensions
The following attributes are in addition to those attributes specified in C.2.5 of X.420.
(NU) Attributes bearing the names of heading fields with those fields as their values.
-- Military Heading Fields
exempted-address ATTRIBUTE
WITH ATTRIBUTE-SYNTAX ExemptedAddress
MATCHES FOR EQUALITY
MULTI VALUE
::= id-nato-mmhs-hat-exempted-address
extended-authorisation-info ATTRIBUTE
WITH ATTRIBUTE-SYNTAX ExtendedAuthorisationInfo
SINGLE VALUE
::= id-nato-mmhs-hat-extended-authorisation-info
distribution-codes ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DistributionCodes
MULTI VALUE
::= id-nato-mmhs-hat-distribution-codes
handling-instructions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX HandlingInstructions
SINGLE VALUE
::= id-nato-mmhs-hat-handling-instructions
sic-codes ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Sic
MULTI VALUE
::= id-nato-mmhs-hat-sic-codes
distribution-extensions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DistributionExtensionField
-- The dist-value field shall be disregarded for the purpose of
-- matching, unless the syntax of the field is recognized based
-- on the value of the dist-type field.
MULTI VALUE
::= id-nato-mmhs-hat-distribution-extensions
message-instructions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX MessageInstructions
SINGLE VALUE
::= id-nato-mmhs-hat-message-instructions

codress-message ATTRIBUTE
WITH ATTRIBUTE-SYNTAX CodressMessage
SINGLE VALUE
::= id-nato-mmhs-hat-codress-message
originator-reference ATTRIBUTE
WITH ATTRIBUTE-SYNTAX OriginatorReference
SINGLE VALUE
::= id-nato-mmhs-hat-originator-reference
primary-precedence ATTRIBUTE
WITH ATTRIBUTE-SYNTAX MMHSPrecedence
SINGLE VALUE
::= id-nato-mmhs-hat-primary-precedence
copy-precedence ATTRIBUTE
SINGLE VALUE
::= id-nato-mmhs-hat-copy-precedence
message-type ATTRIBUTE
WITH ATTRIBUTE-SYNTAX MessageType
SINGLE VALUE
::= id-nato-mmhs-hat-message-type
address-list-indicator ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AddressListDesignator
MULTI VALUE
::= id-nato-mmhs-hat-address-list-indicator
other-recipients-indicator ATTRIBUTE
WITH ATTRIBUTE-SYNTAX OtherRecipientDesignator
MULTI VALUE
::= id-nato-mmhs-hat-other-recipients-indicator
pilot-forwarding-info ATTRIBUTE
WITH ATTRIBUTE-SYNTAX PilotInformation
MULTI VALUE
::= id-nato-mmhs-hat-pilot-forwarding-info
acp127-message-identifier ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Acp127MessageIdentifier
SINGLE VALUE
::= id-nato-mmhs-hat-acp127-message-identifier

originator-plad ATTRIBUTE
WITH ATTRIBUTE-SYNTAX OriginatorPlad --modified
SINGLE VALUE
::= id-nato-mmhs-hat-originator-plad
acp127-notification-request ATTRIBUTE
-- an extension of Recipient Specifier
WITH ATTRIBUTE-SYNTAX Acp127NotificationType
SINGLE VALUE
::= id-nato-mmhs-hat-acp127-notification-request
C1.1 ACP 127 Notification Fields
The following attribute is an additional attribute for ACP notifications.
acp127-notification-response ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Acp127NotificationResponse
MULTI VALUE -- The reponse is multi-value
::= id-nato-mmhs-nat-acp127-notification-response

ANNEX D - Reference Definition of Object Identifiers
(NU) The Military Object Identifiers defined below are a super-set of the civil IPMS
Object Identifiers defined in Annex D to X.420/IS 10021-7, all of which are imported into
the military messaging system.
MMSObjectIdentifiers {iso(1) identified-organization(3) nato(26) stanags(0)

mmhs(4406)object-identifiers (0)}
DEFINITIONS IMPLICIT TAGS ::=

BEGIN
-- Prologue
-- Export everything
IMPORTS --nothing-- ;
ID ::= OBJECT IDENTIFIER
-- Military Messaging
id-mmhs ID ::= {iso(1) identified-organization(3) nato(26) stanags(0) mmhs(4406)

object-identifiers(0)}
-- Categories of object identifiers
id-mod ID ::= {id-mmhs 0} -- mm module

id-mm ID ::= {id-mmhs 2} -- heading extension
id-hat ID ::= {id-mmhs 3} -- heading attributes for MS
id-mcont ID ::= {id-mmhs 4} -- content types
id-policy ID ::= {id-mmhs 5} -- NATO policy identifier
id-cat ID ::= {id-mmhs 6} -- special category identifiers
id-et ID ::= {id-mmhs 7} -- military defined extended body part types
id-mmts ID ::= {id-mmhs 8} -- mts object identifiers
id-nat ID ::= {id-mmhs 9} -- military defined notification attributes
id-mot ID ::= {id-mmhs 10} -- military object types
id-mpt ID ::= {id-mmhs 11} -- military port types
id-ref ID ::= {id-mmhs 12} -- refinements
id-informationlabel ID ::= {id-mmhs 13}
-- Modules
-- MMS information objects

id-mod-upper-bounds ID ::= {id-mod 0}
id-mod-mms ID ::= {id-mod 1}
id-mod-functional-objects ID ::= {id-mod 2}
id-mod-abstract-service ID ::= {id-mod 3}
id-mod-heading-extension ID ::= {id-mod 6}
id-mod-extended-body-part-types ID ::= {id-mod 7}
id-mod-message-store-attributes ID ::= {id-mod 8}
id-mod-per-recipient-specifier-extensions ID ::= {id-mod 11}
id-mod-other-notification-type-extensions ID ::= {id-mod 12}

-- Object types
id-mot-mmme ID ::= {id-mot 0}

id-mot-mms-user ID ::= {id-mot 1}
id-mot-mms ID ::= {id-mot 2}
id-mot-mms-ua ID ::= {id-mot 3}
id-mot-mms-ms ID ::= {id-mot 4}
id-mot-acp127au ID ::= {id-mot 5}
id-mot-pdau ID ::= {id-mot 6}
-- port types
id-mpt-origination ID ::= {id-mpt 0}

id-mpt-reception ID ::= {id-mpt 1}
id-mpt-management ID ::= {id-mpt 2}
-- Refinements
id-ref-primary ID ::= {id-ref 0}

id-ref-secondary ID ::= {id-ref 1}
-- Military Defined body parts
id-nato-mmhs-et-adatp3 ID ::= {id-et 0}

id-nato-mmhs-et-corrections ID ::= {id-et 1}
id-nato-mmhs-et-adatp3-parameters ID ::= {id-et 2}
id-nato-mmhs-et-corrections-parameters ID ::= {id-et 3}
id-nato-mmhs-et-forwarded-encrypted ID ::= {id-et 6}
id-nato-mmhs-et-forwarded-encrypted-parameters ID ::= {id-et 7}
id-nato-mmhs-et-mm-message ID ::= {id-et 9}
id-nato-mmhs-et-mm-message-parameters ID ::= {id-et 10}
id-nato-mmhs-et-mm-acp127data ID ::= {id-et 12}
id-nato-mmhs-et-mm-acp127data-parameters ID ::= {id-et 13}
-- Military Defined Heading Fields
id-nato-mmhs-mm-primary-precedence ID ::= {id-mm 0}

id-nato-mmhs-mm-copy-precedence ID ::= {id-mm 1}
id-nato-mmhs-mm-message-type ID ::= {id-mm 2}
id-nato-mmhs-mm-address-list-indicator ID ::= {id-mm 3}
id-nato-mmhs-mm-exempted-address ID ::= {id-mm 4}
id-nato-mmhs-mm-extended-authorisation-info ID ::= {id-mm 5}
id-nato-mmhs-mm-distribution-codes ID ::= {id-mm 6}
id-nato-mmhs-mm-handling-instructions ID ::= {id-mm 7}
id-nato-mmhs-mm-message-instructions ID ::= {id-mm 8}
id-nato-mmhs-mm-codress-message ID ::= {id-mm 9}
id-nato-mmhs-mm-originator-reference ID ::= {id-mm 10}
id-nato-mmhs-mm-other-recipients-indicator ID ::= {id-mm 11}
id-nato-mmhs-mm-pilot-forwarding-info ID ::= {id-mm 12}
id-nato-mmhs-mm-acp127-message-identifier ID ::= {id-mm 13}
id-nato-mmhs-mm-originator-plad ID ::= {id-mm 14}
-- the following are per-recipient
id-nato-mmhs-mm-acp127-notification-request ID ::= {id-mm 15}
-- the following are per other-notification-type
id-nato-mmhs-mm-acp127-notification-response ID :: {id-mm 16}

-- Military Defined Heading Attributes for MS
id-nato-mmhs-hat-primary-precedence ID ::= {id-hat 0}

id-nato-mmhs-hat-copy-precedence ID ::= {id-hat 1}
id-nato-mmhs-hat-message-type ID ::= {id-hat 2}
id-nato-mmhs-hat-address-list-indicator ID ::= {id-hat 3}
id-nato-mmhs-hat-exempted-address ID ::= {id-hat 4}
id-nato-mmhs-hat-extended-authorisation-info ID ::= {id-hat 5}
id-nato-mmhs-hat-distribution-codes ID ::= {id-hat 6}
id-nato-mmhs-hat-handling-instructions ID ::= {id-hat 7}
id-nato-mmhs-hat-message-instructions ID ::= {id-hat 8}
id-nato-mmhs-hat-codress-message ID ::= {id-hat 9}
id-nato-mmhs-hat-originator-reference ID ::= {id-hat 10}
id-nato-mmhs-hat-other-recipients-indicator ID ::= {id-hat 11}
id-nato-mmhs-hat-pilot-forwarding-info ID ::= {id-hat 12}
id-nato-mmhs-hat-acp127-message-identifier ID ::= {id-hat 13}
id-nato-mmhs-hat-originator-plad ID ::= {id-hat 14}
-- the following are per-recipient
id-nato-mmhs-hat-acp127-notification-request ID ::= {id-hat 15}
id-nato-mmhs-hat-sic-codes ID ::= {id-hat 16}
id-nato-mmhs-hat-distribution-extensions ID ::= {id-hat 17}
-- Military Defined special category identifiers
id-nato-mmhs-cat ID ::= {id-cat 0}

id-nato-mmhs-cat-atomal ID ::= {id-cat 1}
id-nato-mmhs-cat-cryptosecurity ID ::= {id-cat 2}
id-nato-mmhs-cat-specialhandlingintel ID ::= {id-cat 3}
id-nato-mmhs-cat-ussiopesi ID ::= {id-cat 4}
id-nato-mmhs-cat-eyesonly ID ::= {id-cat 5}
id-nato-mmhs-cat-exclusive ID ::= {id-cat 6}
id-nato-mmhs-cat-information-label ID ::= {id-cat 7}
id-nato-mmhs-informationlabel-atomal ID ::= {id-informationlabel 1}

id-nato-mmhs-informationlabel-cryptosecurity ID ::= {id-informationlabel 2}
id-nato-mmhs-informationlabel-specialhandlingintel
ID ::= {id-informationlabel 3}
id-nato-mmhs-informationlabel-ussiopesi ID ::= {id-informationlabel 4}
id-nato-mmhs-informationlabel-eyesonly ID ::= {id-informationlabel 5}
id-nato-mmhs-informationlabel-exclusive ID ::= {id-informationlabel 6}
-- Military Defined Notification Extension
id-nato-mmhs-nat-acp127-notification-response ID ::= {id-nat 0}
-- Military Message content types (for use by MS only)
id-mct-p772 ID ::= {id-mcont 1}
END -- of MMHSObjectIdentifiers

ANNEX E - Reference Definition of Abstract Information Objects
(NU) This annex, a supplement to section 2 of the MBS, defines the abstract information
object for military messaging.
MMSInformationObjects {ISO(1)identified-organization(3)NATO(26)
STANAGS(0)MMHS(4406)object-identifiers(0)module(0)mms(1)}

BEGIN
--Prologue
-- Exports Everything
IMPORTS
-- IPM Information Object
Body, CommonFields, Heading, NonReceiptFields,

OtherNotificationTypeFields,ReceiptFields
---
FROM IPMSInformationObjects {joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) information-objects(2)}
-- MTS abstract service

ORName
---
FROM MTSAbstractService {joint-iso-ccitt
mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)};
-- Information Object
InformationObject ::= CHOICE {

mm [0] MM,
mn [1] MN}
-- MM (Military Message)
MM ::= SEQUENCE {
mmheading Heading,
mmbody Body}
-- The mandatory support on the IPMIdentifier components is

-- more important in MMS than in IPMS.
-- The user component, ORName of the originating UA is mandatory.
-- LocalIPMIdentifier is made up of 2 concatenated string separated
-- by a space both generated by the originating UA, a serial number
-- and the filling time (the time the message generation is finished)
-- in UTC time format. The minimum length of 15 is because both a
-- date/time stamp
--

-- MN (Military Notification receipt/non receipt / other notification types)
MN ::= SET {
COMPONENTS OF CommonFields,
choice [0] CHOICE {
mn-non-receipt-fields [0] NonReceiptFields,
mn-receipt-fields [1] ReceiptFields,
mn-other-notification-type-fields [2] OtherNotificationTypeFields}}
MRN ::= MN-- with MN-receipt-fields chosen
MNRN ::= MN -- with MN-non-receipt-fields chosen
MON ::= MN-- with MN-other-notification-type-fields chosen
-- All military specific body parts are defined as extended body parts.
-- The military specific body parts are defined in Annex A
-- of this part of the MBS.
END -- of MMS InformationObjects

ANNEX F - Reference Definition of Functional Objects
(NU) This annex, a supplement to '' 10, 11 and 16 of the MBS, defines for reference
purposes the functional objects of military messaging. It uses the OBJECT and REFINE
macros of Recommendation X.407.
MMSFunctionalObjects {ISO(1)identified-organization(3)NATO(26)
STANAGS(0)MMHS(4406)object-identifiers(0)module(0)functional-objects(2)}

BEGIN
--Prologue
IMPORTS
-- MMS abstract service

management, origination, reception
---
FROM MMSAbstractService {ISO(1)identified-organization(3)NATO(26)
STANAGS(0)MMHS(4406)object-identifiers(0)module(0)
abstract-service(3)}
-- MMS object identifiers

id-mot-acp127au,id-mot-mmme, id-mot-mms, id-mot-mms-ms,
id-mot-mms-ua, id-mot-mms-user, id-mot-pdau, id-ref-primary,
id-ref-secondary
---
FROM MMSObjectIdentifiers {ISO(1)identified-organization(3)NATO(26)
STANAGS(0)MMHS(4406)object-identifiers(0)}
-- MS abstract service
retrieval
---
FROM MSAbstractService {joint-iso-ccitt
mhs-motis(6) ms(4) modules(0) abstract-service(1)}

administration, delivery, mTS, submission
---
mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)}
-- Abstract service definition conventions

OBJECT, REFINE
---
FROM AbstractServiceNotation {joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)};

-- ARoot@ object type
mmme OBJECT
::= id-mot-mmme
-- Primary refinement
mmme-refinement REFINE mmme AS

mms
origination [S] PAIRED WITH mms-user
reception[S] PAIRED WITH mms-user
management [S] PAIRED WITH mms-user
mms-user RECURRING
::= id-ref-primary
-- Primary object types
mms-user OBJECT
PORTS{
origination [C],
reception [C],
management [C]}
::= id-mot-mms-user
mms OBJECT
PORTS{
origination [S],
reception [S],
management [S]}
::= id-mot-mms
-- Secondary refinement
mms-refinement REFINE MMS AS

mTS
submission [S] PAIRED WITH mms-ua, mms-ms
delivery [S] PAIRED WITH mms-ua, mms-ms
administration [S] PAIRED WITH mms-ua, mms-ms
mms-ua RECURRING
origination [S] VISIBLE
reception [S] VISIBLE
management [S] VISIBLE
mms-ms RECURRING
submission [S] PAIRED WITH mms-ua
retrieval [S] PAIRED WITH mms-ua
administration [S] PAIRED WITH mms-ua
acp127au RECURRING
origination [S] VISIBLE
management [S] VISIBLE
pdau RECURRING
::= id-ref-secondary

--Secondary objects
mms-ua OBJECT
PORTS{
origination [S],
reception [S],
management [S],
submission [C],
delivery [C],
retrieval [C],
administration [C]}
::= id-mot-mms-ua
mms-ms OBJECT
PORTS{
submission [S],
retrieval [S],
administration [S],
submission [C],
delivery [C],
administration [C]}
::= id-mot-mms-ua
pdau OBJECT
PORTS {
reception [S]}
::= id-mot-pdau
acp127au OBJECT
PORTS{
origination [S],
reception[S],
management [S]}
::= id-mot-acp127au
END --of MMSFunctionalObjects

ANNEX G - Reference Definition of Abstract Service
(NU) This annex, a supplement to clauses 12 and 13 of the MBS, defines for reference
purposes the MMS abstract service. It uses the PORT, ABSTRACT-OPERATION and
ABSTRACT-ERROR macros of Recommendation X.407.
MMSAbstractService {ISO(1)identified-organization(3)NATO(26)
STANAGS(0)MMHS(4406)object-identifiers(0)module(0)abstract-service(3)}

BEGIN
--Prologue
IMPORTS
-- IPMS information objects

AutoForwardComment, Heading
---

MM, MN, MNRN, MRN, MON, InformationObject
---
FROM MMSInformationObjects {ISO(1)identified-organization(3)NATO(26)
mms(1)}

id-mpt-management, id-mpt-origination, id-mpt-reception
---

MessageDeliveryEnvelope, MessageSubmissionEnvelope,
MessageSubmissionIdentifier, MessageSubmissionTime,
ORName, ProbeSubmissionenvelope, ProbeSubmissionIdentifier,
ProbeSubmissionTime, RecipientImproperlySpecified,
ReportDeliveryEnvelope, SupplementaryInformation
---
mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)}
-- Abstract service definition conventions

ABSTRACT-ERROR, ABSTRACT-OPERATION, PORT
---
FROM AbstractServiceNotation {joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)};

-- Ports
origination PORT
CONSUMER INVOKES{
OriginateProbe, -- Although, national implementation may
-- support probes within their own domain, probes are
not
-- permitted across national boundaries
OriginateMM,
OriginateMRN}
::= id-pt-origination
reception PORT
CONSUMER INVOKES{
ReceiveReport,
ReceiveMM,
ReceiveMRN,
ReceiveMNRN,
ReceiveMON}
::= id-pt-reception
management port
CONSUMER INVOKES{
ChangeAutoDiscard,
ChangeAutoAcknowledgment,
ChangeAutoForwarding}
::= id-pt-management
-- Origination abstract operations
-- Probes are prohibited across national boundaries.
OriginateProbe ::= ABSTRACT-OPERATION

ARGUMENT SET {
envelope [0] ProbeSubmissionEnvelope,
content [1] MM}
RESULT SET
submission-identifier [0] ProbeSubmissionIdentifier,
submission-time [1] ProbeSubmissionTime}
ERROR {
SubcriptionError,
RecipientImproperlySpecified}
OriginateMM ::= ABSTRACT-OPERATION

ARGUMENT SET {
envelope [0] MessageSubmissionEnvelope,
content [1] MM}
RESULT SET {
submission-identifier [0] MessageSubmissionIdentifier,
submission-time [1] MessageSubmissionTime}
ERROR {
SubcriptionError,

OriginateMRN ::= ABSTRACT-OPERATION

ARGUMENT SET {
envelope [0] MessageSubmissionEnvelope,
content [1] MRN}
RESULT SET {
submission-identifier [0] MessageSubmissionIdentifier,
submission-time [1] MessageSubmissionTime}
ERROR {
SubcriptionError,
-- Reception abstract operations
ReceiptReport ::= ABSTRACT-OPERATION

ARGUMENT SET {
envelope [0] ReportDeliveryEnvelope,
undelivered-object [1] InformationObject OPTIONAL}
RESULT
ERROR {}
ReceiptMM ::= ABSTRACT-OPERATION

ARGUMENT SET {
envelope [0] MessageDeliveryEnvelope,
content [1] MM}
RESULT
ERROR {}
ReceiptMRN ::= ABSTRACT-OPERATION

ARGUMENT SET {
content [1] MRN}
RESULT
ERROR {}
ReceiptMNRN ::= ABSTRACT-OPERATION

ARGUMENT SET {
content [1] MNRN}
RESULT
ERROR {}
ReceiptMON ::= ABSTRACT-OPERATION

ARGUMENT SET {
content [1] MON}
RESULT
ERROR {}
-- Management abstract operations

-- It should be noted that in cases where an implementation has dual IPM
-- and MM functionality, the management abstract operations may be used
-- for support of
-- both types of messaging.

ChangeAutoDiscard ::= ABSTRACT-OPERATION

ARGUMENT SET {
auto-discard-expired-MMs [0] BOOLEAN,
auto-discard-obsolete-MMs [1] BOOLEAN}
RESULT
ERRORS {}
ChangeAutoAcknowledgement ::= ABSTRACT-OPERATION

ARGUMENT SET{
auto-acknowledge-MMs [0] BOOLEAN,
auto-acknowledge-suppl-receipt-info [1] SupplementaryInformation}
RESULT
ERRORS{
SubscriptionError }
ChangeAutoForwarding ::= ABSTRACT-OPERATION

ARGUMENT SET {
autoforward-MMs [0] BOOLEAN,
auto-forward-recipients [1] SEQUENCE OF ORName OPTIONAL,
auto-forward-heading [2] Heading OPTIONAL,
auto-forward-comment [3] AutoForwardComment OPTIONAL}
RESULT
ERRORS {
SubscriptionError,
-- Abstract errors
SubscriptionError ::= ABSTRACT-ERROR

PARAMETER SET {
problem [0] SubscriptionProblem}
SubscriptionProblem ::= ENUMERATED {

mms-eos-not-subcribed (0),
mts-eos-not-subcribed (1)}
END --of MMSAbstractService

ANNEX H1 - Reference Definition of Military Heading Extensions
(NU) This annex, a supplement to Annex A1, defines for reference purposes the military
heading extensions defined for military messaging. It uses the IPMS-EXTENSION macro
of clause 7.2.17.
MMSHeadingExtensions {ISO(1)identified-organization(3)NATO(26)
STANAGS(0)MMHS(4406)object-identifiers(0)module(0)heading-extensions(6)}

BEGIN
--Prologue
IMPORTS

IPMS-EXTENSION, ORDescriptor
---
-- MMS upper bounds

lb-military-sic, ub-military-number-of-sics, ub-military-sic
---
FROM MMSUpperBounds {ISO(1)identified-organization(3)NATO(26)
STANAGS(0)MMHS(4406)object-identifiers(0)module(0) upper-bounds(0)}

id-nato-mmhs-mm-acp127-message-identifier,
id-nato-mmhs-mm-address-list-indicator, id-nato-mmhs-mm-codress-message,
id-nato-mmhs-mm-copy-precedence, id-nato-mmhs-mm-distribution-codes,
id-nato-mmhs-mm-exempted-address,
id-nato-mmhs-mm-extended-authorisation-info,
id-nato-mmhs-mm-handling-instructions,
id-nato-mmhs-mm-message-instructions, id-nato-mmhs-mm-message-type,
id-nato-mmhs-mm-originator-reference, id-nato-mmhs-mm-originator-plad,
id-nato-mmhs-mm-other-recipients-indicator,
id-nato-mmhs-mm-pilot-forwarding-info,
id-nato-mmhs-mm-primary-precedence
---

MessageSecurityLabel
---
mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)};

-- exempted address
exempted-address IPMS-EXTENSION
VALUE SEQUENCE OF ExemptedAddress
::= id-nato-mmhs-mm-exempted-address
ExemptedAddress ::= ORDescriptor
-- extended authorisation information
extended-authorisation-info IPMS-EXTENSION
VALUE ExtendedAuthorisationInfo
::= id-nato-mmhs-mm-extended-authorisation-info
ExtendedAuthorisationInfo ::= UTCTime
-- Distribution codes
-- will carry subject indicator codes and leave room for expansion.
distribution-codes IPMS-EXTENSION
VALUE DistributionCodes
::= id-nato-mmhs-mm-distribution-codes
DistributionCodes ::= SET {

sics [0] SEQUENCE SIZE (1..ub-military-number-of-sics)
OF Sic OPTIONAL,
dist-Extensions [1] SEQUENCE OF DistributionExtensionField OPTIONAL}
Sic ::= PrintableString (SIZE (lb-military-sic..ub-military-sic))
DistributionExtensionField ::= SEQUENCE {

dist-type OBJECT IDENTIFIER,
dist-value ANY DEFINED BY dist-type}
-- Handling instructions
handling-instructions IPMS-EXTENSION
VALUE HandlingInstructions
::= id-nato-mmhs-mm-handling-instructions
HandlingInstructions ::= SEQUENCE OF MilitaryString
MilitaryString ::= PrintableString (SIZE(1..ub-military-string))
-- Message instructions
-- will carry operating signals
message-instructions IPMS-EXTENSION
VALUE MessageInstructions
::= id-nato-mmhs-mm-message-instructions
MessageInstructions ::= SEQUENCE OF MilitaryString

-- Codress message
-- Needed for transition or as long as codress messages need to be carried.
codress-message IPMS-EXTENSION
VALUE CodressMessage
::= id-nato-mmhs-mm-codress-message
CodressMessage ::= INTEGER
-- Originator reference
-- only used if a user designated identifier string becomes important.
originator-reference IPMS-EXTENSION
VALUE OriginatorReference
::= id-nato-mmhs-mm-originator-reference
OriginatorReference ::= MilitaryString
-- Primary reference
primary-precedence IPMS-EXTENSION
::= id-nato-mmhs-mm-primary-precedence
MMHSPrecedence ::= INTEGER {deferred (0), routine (1), priority (2),

immediate (3), flash (4), override (5)}
-- Note: Values 0 to 15 are reserved for NATO defined precedence levels.

-- Values 16 to 31 are reserved for national user.
-- Copy precedence
copy-precedence IPMS-EXTENSION
::= id-nato-mmhs-mm-copy-precedence

-- Values 16 to 31 are reserved for national user.
-- Message type
message-type IPMS-EXTENSION
VALUE MessageType
::=id-nato-mmhs-mm-message-type
MessageType ::= SET{

type [0] TypeMessage,
identifier [1] MessageIdentifier OPTIONAL}
TypeMessage ::= INTEGER {exercise(0), operation(1), project(2), drill(3)}
-- Note: Values 0 to 127 are reserved for NATO defined Message Type
-- identifiers. Values above 128 to 255 are not defined by NATO and may
-- be used nationally or bilaterally.

MessageIdentifier ::= MilitaryString
-- Address list indicator
address-list-indicator IPMS-EXTENSION
VALUE SEQUENCE OF AddressListDesignator
::=id-nato-mmhs-mm-address-list-indicator
AddressListDesignator ::=SET {
type [0] INTEGER {primaryAddressList (0),
copyAddressList (1)},
listName [1] ORDescriptor,
notificationRequest [2] AddressListRequest OPTIONAL,
replyRequest [3] AddressListRequest OPTIONAL}
AddressListRequest ::= INTEGER {action(0), info(1), both(2)}
-- Other recipients indicator
other-recipients-indicator IPMS-EXTENSION
VALUE SEQUENCE OF OtherRecipientDesignator
::=id-nato-mmhs-mm-other-recipients-indicator
OtherRecipientDesignator ::= SET {

type [0] INTEGER {primary(0), copy(1)},
designator [1] MilitaryString}
-- pilot forwarding information
pilot-forwarding-info IPMS-EXTENSION
VALUE SEQUENCE OF PilotInformation
::= id-nato-mmhs-mm-pilot-forwarding-info
PilotInformation ::= SEQUENCE {

pilotPrecedence [0] MMHSPrecedence OPTIONAL,

-- Values 16 to 31 are reserved for national use.
pilotRecipient [1] SEQUENCE OF ORDescriptor OPTIONAL,

pilotSecurity [2] MessageSecurityLabel OPTIONAL,
pilotHandling [3] SEQUENCE OF MilitaryString OPTIONAL}
-- Acp127 message identifier

-- a string to store routing indicator, station serial number and julian file
-- time seperated by spaces.
acp127-message-identifier IPMS-EXTENSION
VALUE Acp127MessageIdentifier
::= id-nato-mmhs-mm-acp127-message-identifier
Acp127MessageIdentifier ::= MilitaryString

-- Originator PLAD
originator-plad IPMS-EXTENSION
VALUE OriginatorPlad
::= id-nato-mmhs-mm-originator-plad
OriginatorPlad ::= MilitaryString
END -- of Military heading extensions used in MMS

ANNEX H2 - Reference Definition of per recipient specifier Extensions
(NU) This annex, a supplement to Annex A2, defines for reference purposes the
PerRecipientSpecifier extensions defined for military messaging. It uses the IPMS-
EXTENSION macro of clause 7.2.17.
MMSPerRecipientSpecifierExtensions {ISO(1)identified-organization(3)NATO(26)
per-recipient-specifier-extensions(11)}

BEGIN
--Prologue
IMPORTS

IPMS-EXTENSION
---

id-nato-mmhs-mm-acp127-notification-request
---
STANAGS(0)MMHS(4406)object-identifiers(0)};
-- ACP127 notification request

-- The following definitions are made in order to support
-- informing the originator of a message that the subject message
-- has reached a gateway to an ACP 127 domain.
acp127-notification-request IPMS-EXTENSION
VALUE Acp127NotificationType
::= id-nato-mmhs-mm-acp127-notification-request
Acp127NotificationType ::= BIT STRING {

acp127-nn (0), -- negative notification
acp127-pn (1), -- positive notification
acp127-tn (2)} -- transfer notification
END -- of MMS per recipient pecifier extensions

ANNEX H3 - Reference Definition of OtherNotificationType Extensions
(NU) This annex, a supplement to Annex A3, defines for reference purposes the
OtherNotificationType extensions defined for military messaging. It uses the IPMS-
EXTENSION macro of clause 7.2.17.
MMSOtherNotificationTypeExtensions {ISO(1)identified-organization(3)NATO(26)
other-notification-type-extensions(12)}

BEGIN
--Prologue
IMPORTS

IPMS-EXTENSION, ReceiptTimeField
---
-- MMS upper bounds

ub-military-bigstring
---
FROM MMSUpperBounds {ISO(1)identified-organization(3)NATO(26)
STANAGS(0)MMHS(4406)object-identifiers(0)module(0) upper-bounds(0)}

id-nato-mmhs-mm-acp127-notification-response
---
-- MMS heading extensions

AddressListDesignator
---
FROM MMSHeadingExtensions {ISO(1)identified-organization(3)NATO(26)
heading-extensions(6)}
-- MMS per recipient specifier extensions

Acp127NotificationType
---
FROM MMSPerRecipientSpecifierExtensions {ISO(1)identified-organization(3)
NATO(26)STANAGS(0)MMHS(4406)object-identifiers(0)module(0)
per-recipient-specifier-extensions(11)};
--ACP127 notification response
acp127-notification-response IPMS-EXTENSION
VALUE Acp127NotificationResponse
::= id-nato-mmhs-mm-acp127-notification-response

Acp127NotificationResponse ::= SET {

acp127-notification-type [0] Acp127NotificationType,
receipt-time [1] ReceiptTimeField,
addressListInicator [2] AddressListIndicator OPTIONAL,
acp127-recipient [3] Acp127Recipient OPTIONAL,
acp127-supp-info [4] Acp127SuppInfo OPTIONAL}
AddressListIndicator ::= SEQUENCE OF AddressListDesignator
Acp127Recipient ::= PrintableString (SIZE (1..ub-military-bigstring))
Acp127SuppInfo ::= PrintableString (SIZE (1..ub-military-bigstring))
END -- of MMS OtherNotificationType extensions

ANNEX I1 - Reference Definition of Extended Body Part Types
(NU) This annex, a supplement to Annex B.1 defines for reference purposes the
extended body part types defined for military messaging.
Note, all extended body parts defined in Annex I of X.420 are also valid in an MM
environment.
MMSExtendedBodyPartTypes {ISO(1)identified-organization(3)NATO(26)
extended-body-part-types(7)}

BEGIN
--Prologue
IMPORTS

EXTENDED-BODY-PART-TYPE
---

MM
---
FROM MMSInformationObjects{ISO(1)identified-organization(3)NATO(26)
mms(1)}
-- MMS upper lower bounds

ub-data-size
---
FROM MMSUpperBounds{ISO(1)identified-organization(3)NATO(26)
upper-bounds(0)}
-- MTS Abstract Service

MessageDeliveryTime, OtherMessageDeliveryFields
---
FROM MTSAbstractService {joint-iso-ccitt mhs-motis(6)
mts(3) modules(0) mts-abstract-service(1)}


---
id-nato-mmhs-et-adatp3,
id-nato-mmhs-et-adatp3-parameters,
id-nato-mmhs-et-acp127data,
id-nato-mmhs-et-acp127data-parameters,
id-nato-mmhs-et-corrections,
id-nato-mmhs-et-corrections-parameters,
id-nato-mmhs-et-forwarded-encrypted,
id-nato-mmhs-et-forwarded-encrypted-parameters,
id-nato-mmhs-et-mm-message,
---
-- extended adatp3 bodypart
adatp3-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS ADatP3Parameters IDENTIFIED BY
id-nato-mmhs-et-adatp3-parameters
DATA ADatP3Data
::= id-nato-mmhs-et-adatp3
ADatP3Parameters ::= INTEGER DEFAULT (0)
ADatP3Data ::= CHOICE{

lineOriented [0] IMPLICIT IA5String,
setOriented [1] IMPLICIT SEQUENCE OF IA5String}
-- extended corrections body part
corrections-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS CorrectionsParameters IDENTIFIED BY
id-nato-mmhs-et-corrections-parameters
DATA CorrectionsData
::= id-nato-mmhs-et-corrections
CorrectionsParameters ::= INTEGER
CorrectionsData ::= IA5String
-- extended forwarded encrypted body part
forwarded-encrypted-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS ForwardedEncryptedParameters IDENTIFIED BY
id-nato-mmhs-et-forwarded-encrypted-parameters
DATA ForwardedEncryptedData
::= id-nato-mmhs-et-forwarded-encrypted
-- A forwarded-encrypted-body must contain the delivery information,

-- containing the content type which will indicate whether the forwarded
-- encrypted message is an MM or IPM. All security related information --
-- (i.e., token) of the original message must be forwarded.

ForwardedEncryptedParameters ::= SET {

-- 2/X.411, part 9 of 26.
ForwardedEncryptedData ::= BIT STRING
-- extended MM message body part
mm-message-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS MMMessageParameters IDENTIFIED BY
DATA MMMessageData
::= id-nato-mmhs-et-mm-message
-- An mm-message-body-part can either carry a forwarded MM or a forwarded

-- IPM. In the case of a message-body-part, as defined in X.420,
-- it can only carry an IPM.
MMMessageParameters ::= SET {

MMMessageData ::= MM
-- extended acp127data body part
acp127data-body-part EXTENDED-BODY-PART-TYPE
PARAMETERS ACP127DataParameters IDENTIFIED BY
id-nato-mmhs-et-acp127data-parameters
DATA ACP127DataData
::= id-nato-mmhs-et-acp127data
ACP127DataParameters ::= INTEGER
ACP127DataData ::= IA5String (SIZE(1..ub-data-size))
END -- of MMS ExtendedBodyPartTypes

ANNEX J1 - Reference Definition of Message Store Attributes
(NU) This annex is a supplement to annex C and defines, for reference purposes, the
MS attributes specific to military messaging (MM-MS). The MM-MS attributes are a
super-set of Interpersonal Messaging attributes defined in CCITT X.420/IS 10021-7, as
such only the delta is defined here.
MMSMessageStoreAttributes {ISO(1)identified-organization(3)NATO(26)
message-store-attributes(8)}

BEGIN
--Prologue
IMPORTS
-- MMS heading extensions

Acp127MessageIdentifier,
AddressListDesignator,
CodressMessage,
DistributionCodes,
DistributionExtensionField,
Sic,
ExemptedAddress,
ExtendedAuthorisationInfo,
HandlingInstructions,
MessageInstructions,
MessageType,
MMHSPrecedence,
OriginatorPlad,
OriginatorReference,
OtherRecipientDesignator,
PilotInformation
---
FROM MMSHeadingExtensions {ISO(1)identified-organization(3)NATO(26)
heading-extensions(6)}
-- MMS per recipient specifier extensions

Acp127NotificationType
---
FROM MMSPerRecipientSpecifierExtensions {ISO(1)
identified-organization(3)NATO(26)STANAGS(0)MMHS(4406)
object-identifiers(0)module(0)per-recipient-specifier-
extensions(11)}

-- MMS other notification type extensions

Acp127NotificationResponse
---
FROM MMSOtherNotificationTypeExtensions {ISO(1)
identified-organization(3)NATO(26)STANAGS(0)MMHS(4406)
object-identifiers(0)module(0)other-notification-type-extensions(12)}

id-nato-mmhs-hat-acp127-notification-request,
id-nato-mmhs-hat-acp127-message-identifier,
id-nato-mmhs-hat-address-list-indicator,
id-nato-mmhs-hat-copy-precedence,
id-nato-mmhs-hat-codress-message,
id-nato-mmhs-hat-distribution-codes,
id-nato-mmhs-hat-distribution-extensions,
id-nato-mmhs-hat-extended-authorisation-info,
id-nato-mmhs-hat-exempted-address,
id-nato-mmhs-hat-handling-instructions,
id-nato-mmhs-hat-message-type,
id-nato-mmhs-hat-message-instructions,
id-nato-mmhs-hat-originator-reference,
id-nato-mmhs-hat-originator-plad,
id-nato-mmhs-hat-other-recipients-indicator,
id-nato-mmhs-hat-pilot-forwarding-info,
id-nato-mmhs-hat-primary-precedence,
id-nato-mmhs-hat-sic-codes,
id-nato-mmhs-nat-acp127-notification-response
---
exempted-address ATTRIBUTE
WITH ATTRIBUTE-SYNTAX ExemptedAddress
MULTI VALUE
::= id-nato-mmhs-hat-exempted-address
extended-authorisation-info ATTRIBUTE
WITH ATTRIBUTE-SYNTAX ExtendedAuthorisationInfo
SINGLE VALUE
::= id-nato-mmhs-hat-extended-authorisation-info
distribution-codes ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DistributionCodes
MULTI VALUE
::= id-nato-mmhs-hat-distribution-codes
handling-instructions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX HandlingInstructions
SINGLE VALUE
::= id-nato-mmhs-hat-handling-instructions

sic-codes ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Sic
MULTI VALUE
::= id-nato-mmhs-hat-sic-codes
distribution-extensions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX DistributionExtensionField
-- The dist-value field shall be disregarded for the purpose of matching,
-- unless the syntax of the field is recognized based on the value of the
-- dist-type field.
MULTI VALUE
::= id-nato-mmhs-hat-distribution-extensions
message-instructions ATTRIBUTE
WITH ATTRIBUTE-SYNTAX MessageInstructions
SINGLE VALUE
::= id-nato-mmhs-hat-message-instructions
codress-message ATTRIBUTE
WITH ATTRIBUTE-SYNTAX CodressMessage
SINGLE VALUE
::= id-nato-mmhs-hat-codress-message
originator-reference ATTRIBUTE
WITH ATTRIBUTE-SYNTAX OriginatorReference
SINGLE VALUE
::= id-nato-mmhs-hat-originator-reference
primary-precedence ATTRIBUTE
SINGLE VALUE
::= id-nato-mmhs-hat-primary-precedence
copy-precedence ATTRIBUTE
SINGLE VALUE
::= id-nato-mmhs-hat-copy-precedence
message-type ATTRIBUTE
WITH ATTRIBUTE-SYNTAX MessageType
SINGLE VALUE
::= id-nato-mmhs-hat-message-type

address-list-indicator ATTRIBUTE
WITH ATTRIBUTE-SYNTAX AddressListDesignator
MULTI VALUE
::= id-nato-mmhs-hat-address-list-indicator
other-recipients-indicator ATTRIBUTE
WITH ATTRIBUTE-SYNTAX OtherRecipientDesignator
MULTI VALUE
::= id-nato-mmhs-hat-other-recipients-indicator
pilot-forwarding-info ATTRIBUTE
WITH ATTRIBUTE-SYNTAX PilotInformation
MULTI VALUE
::= id-nato-mmhs-hat-pilot-forwarding-info
acp127-message-identifier ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Acp127MessageIdentifier
SINGLE VALUE
::= id-nato-mmhs-hat-acp127-message-identifier
originator-plad ATTRIBUTE
WITH ATTRIBUTE-SYNTAX OriginatorPlad
SINGLE VALUE
::= id-nato-mmhs-hat-originator-plad
acp127-notification-request ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Acp127NotificationType
SINGLE VALUE
::= id-nato-mmhs-hat-acp127-notification-request
-- NOTIFICATIONS
-- ACP 127 Notification Response
acp127-notification-response ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Acp127NotificationResponse
MULTI VALUE
::= id-nato-mmhs-nat-acp127-notification-response
END -- of MMSMessagesStoreAttributes

ANNEX K - Reference Definition of MMS upper bounds
(NU) This annex defines, for reference purposes, the upper bounds of various variable-
length information items whose abstract syntaxes are defined in the ASN.1 modules of
prior annexes.
MMSUpperBounds {ISO(1)identified-organization(3)NATO(26)STANAGS(0)
MMHS(4406)object-identifiers(0)module(0)upper-bounds(0)}

BEGIN
--Prologue
IMPORTS -- nothing --;
-- Upper Bounds
ub-military-string INTEGER ::= 69
ub-military-number-of-sics INTEGER ::= 8
lb-military-sic INTEGER ::= 3
ub-military-sic INTEGER ::= 8
ub-military-bigstring INTEGER ::= 128

ub-data-size INTEGER ::= 65535 -- size of ACP127DATADATA
END -- of MMSUpperBouds

MMHS EXTENSIONS FOR P22 PROTOCOL
No change from civilian standard.

UNCLASSIFIED ANNEX B to ACP 123
Annex B
Information Object Implementation Conformance Statement Proforma
1 Scope
This annex is an Information Object Implementation Conformance Statement (IO-ICS) Proforma for the
MM information object as specified in ACP123. This IO-ICS Proforma is in compliance with the relevant
requirements, and in accordance with the relevant guidance for IO-ICS Proforma given in ISO/IEC 9642-
7.
Details of the use of this proforma are provided in Appendix A.
The scope of this annex is the specification of the conformance statements for the content specific
functionality for any implementation that supports the MM content type. It has been developed by
examining the ASN.1 defined in Annex A of this document. If an ASN.1 element is optional then the
corresponding classification applied to the element in this IO-ICS Proforma is optional. If an ASN.1
element is optional then the corresponding classification applied to the element in this IO-ICS Proforma
is mandatory. Implementors shall state herein the level of support for all MM EoS and protocol
elements.
2 Normative references
The following documents contain provisions which, through reference in this text, constitute provisions of
this annex of ACP 123. At the time of publication, the editions indicated were valid. All documents are
subject to revision, and parties to agreements based on this ICS are warned against automatically
applying any more recent editions of the documents listed below, since the nature of references made by
ICSs to such documents is that they may be specific to a particular edition. Members of IEC and ISO
maintain registers of currently valid International Standards and ISPs, and CCITT maintains published
editions of its current Recommendations.
Technical corrigenda to the base standards referenced are listed in annex B.
NOTE – References in the body of this IO-ICS to specific clauses of ISO/IEC documents shall be considered to
refer also to the corresponding clauses of the equivalent CCITT Recommendations (as noted below) unless
otherwise stated.
– ISO/IEC 9646-1: 1991, Information technology – Open Systems Interconnection –

Conformance testing methodology and framework Part 1: General concepts.
– ISO/IEC 9646-7: 1992, Information technology – Open Systems Interconnection –
Conformance testing methodology and framework Part 7: Implementation Conformance
Statements.
– ISO/IEC 8824: 1990, Information processing systems – Open Systems Interconnection –
Specification of Abstract Syntax Notation One (ASN.1).
– ISO/IEC 8859: 1992, Information technology – 8-bit single-byte coded graphic character sets.
– ISO/IEC 8613-1: 1993, Information technology – Open Document Architecture (ODA) and
Interchange Format – Part 1: Introduction and general principles.
– ISO/IEC 10021-1: 1990, Information technology – Text Communication – Message-Oriented
Text Interchange Systems (MOTIS) – Part 1: Service Overview. [see also CCITT
Recommendation X.400(1992)].
DRAFT
UNCLASSIFIED B-1 ORIGINAL

Text Interchange Systems (MOTIS) – Part 2: Overall Architecture. [see also CCITT
Recommendation X.402(1992)].
Text Interchange Systems (MOTIS) – Part 7: Interpersonal messaging system. [see also
CCITT Recommendation X.420(1992)].
– CCITT Recommendation X.400(1992), Message handling system and service overview.
– CCITT Recommendation X.402(1992), Message handling systems: Overall architecture.
– CCITT Recommendation X.420(1992), Message handling systems: Interpersonal messaging
system.
– ISO/IEC 10021-1:1990/Am.2, Information technology – Message-Oriented Text Interchange
System (MOTIS) – Part 1: System and Service Overview, Amendment 2 Message Store
Extensions 1994.
System (MOTIS) – Part 2: Overall Architecture; Amendment 1: Representation of O/R
Addresses for Human Exchange 1994.
System (MOTIS) – Part 2: Overall Architecture; Amendment 2: Minor Enhancements:
Multinational Organizations and Terminal-form Addresses 1994.
– MHS Implementors' Guide, Version 11, July 1994 (ITU-T Special Rapporteur's Group on
Message Handling Systems and ISO/IEC JTC1/SC18/WG4 SWG on Messaging).
3 Definitions
Terms used in this IO-ICS are defined in ACP 123.
This Specification uses the following terms defined in ISO/IEC 9646-1
Implementation Conformance Statement proforma

Implementation Conformance Statement
Information Object Implementation Conformance Statement proforma
Information Object Implementation Conformance Statement
4 Abbreviations
ACP127 ACP 127 Interworking

AMH Application Message Handling
ASN.1 Abstract Syntax Notation One
ICS Implementation Conformance Statement
MHS Message Handling Systems
MM Military Messaging (Message)
MS Message Store
DRAFT
MT Message Transfer
MTA Message Transfer Agent
MTS Message transfer System
OSI Open Systems Interconnection
UA User Agent
5 Conventions
The IO-ICS Proforma is designed as an appendix to this annex (see Appendix A).
6 Conformance
The supplier of an information object implementation that is claimed to conform to MM is required to

complete a copy of the IO-ICS Proforma provided in Appendix A and is required to provide the
information necessary to identify both the supplier and the implementation.
The scope of conformance to this IO-ICS covers content specific functionality for any implementation
that supports the MM content type. Conformance to this IO-ICS does not imply the provision of a
standard OSI communications protocol for access to the MTS.
This IO-ICS states requirements upon implementations to achieve interworking. A claim of conformance
to this IO-ICS is a claim that all requirements in the relevant base standards are satisfied, and that all
requirements in the following clauses and in appendix A of this IO-ICS are satisfied. Appendix A states
the relationship between these requirements and those of the base standards.
6.1 Conformance statement
For each implementation claiming conformance to ACP 123 as specified in this IO-ICS, an ICS shall be
made available stating support or non-support of each option identified in this IO-ICS.
6.2 MHS conformance
This IO-ICS specifies implementation options or selections such that conformant implementations will
satisfy the non-procedural conformance requirements of ACP 123 as well as those of ISO/IEC 10021.
Implementations whose information objects conform to ACP 123 as specified in this IO-ICS shall
implement all the mandatory support (m) features identified as base requirements in appendix A of this
IO-ICS, and shall state which optional support (o) features are implemented. An implementation of any
EoS for which a select (s) classification has been assigned in section A.8.1 must demonstrate the user's
ability to invoke all legal values for that EoS. An implementation of any EoS for which a display (D)
classification has been assigned in section A.8.1 must display some indication of the received value for
that EoS to the user.
DRAFT
6.3 Error handling
Various distinguished integer values may be defined in supplements to ACP 123 that are not defined in
the base ACP. These are not expected to cross national boundaries without bilateral agreement. When
an unknown distinguished value is encountered, it should, in general, not result in an error. The value
should be treated transparently or ignored, wherever possible. When an unknown distinguished value is
encountered in connection with an EoS that is classified for display (D) in section A.8.1, the
implementation should attempt to convey the unknown value to the user.
DRAFT
Appendix A
(normative)
IO-ICS Proforma for ACP 123
A.1 Identifications
A.1.1 Identification of IO-ICS
Item Question Response
1 Date of statement (DD/MM/YY)
2 IO-ICS serial number
3 System conformance statement cross

reference
A.1.2 Identification of Implementation and/or system
1 Implementation name
2 Implementation version
3 Machine name
4 Machine version
5 Operating system name
6 Operating system version
7 Special configuration
8 Other information
IO-ICS Proforma for ACP 123 (Appendix A to Annex B)

A.1.3 Identification of system supplier and/or test laboratory client
1 Organization name
2 Contact name(s)
3 Address
4 Telephone number
5 Telex number
6 Fax number
7 E-mail address
8 Other information
A.2 Identification of information object
1 Title, reference number and date of publication

of the information object standard
2 IO version(s)
3 Addenda/amendments/corrigenda
implemented
4 Defect reports implemented
A.3 Global statement of conformance
Item Question Response Comments
1 Are all mandatory base standards

requirements implemented?
NOTE – Answering “No” to this section indicates non-conformance to the information object
specification. Unsupported mandatory capabilities are to be identified in the IO-ICS, with an explanation
of why the implementation is non-conformant. Such information shall be provided in A.8, “Other
information”.
A.4 Instructions for completing the IO-ICS Proforma
A.4.1 Definition of support
A capability is said to be supported if the Implementation Under Test (IUT) is able:
– To generate the corresponding service parameters (either automatically or because the end
user explicitly requires the capability);

– To interpret, handle and when required make available to the end user the corresponding
service parameter(s).
A capability is referred to as either originator capability (when the MHS end-user is acting as an
originator) or a recipient capability (when an MHS end-user is acting as a recipient)
An information object element is said to be supported for origination if the IUT is able to generate it
under some circumstances (either automatically or because end-user explicitly requires the related
capability).
An information object element is said to be supported for reception if it is correctly interpreted and
handled and also when required, made available to the end-user.
A.4.2 Base column
The column indicates the level of support required for conformance to MM.
The values are as follows:
m Mandatory support is required. The element or feature is required to be implemented, and

shall be fully supported in conformance with the Specification. An implementation shall be
able to generate the element, and/or receive the element and perform all associated
procedures (i.e., implying the ability to handle both the syntax and semantics of the element)
as relevant, as specified in the MM base standards. Where support for origination
(generation) and reception are not distinguished, then both capabilities shall be assumed.
NOTE – Where required by the base standard, mandatory support also implies that the
implementation shall be able to pass the element on the origination port/reception port
to/from the corresponding element on the submission port/delivery port/retrieval port.
o Optional support is permitted for conformance to ACP 123. The capability may be
implemented, and if it is implemented it is required to conform to the Specification. An
implementation is not required to support the element. If support is claimed, the element
shall be treated as if it were specified as mandatory support. If support for origination is not
claimed, then the element is not generated. If support for reception is not claimed, then an
implementation may ignore the element on delivery, but will not treat it as an error.
c The item is conditional; the support of this item is subject to a predicate which is referenced
in the note column. If these predicate's conditions are met, the element shall be treated as if
it were specified as mandatory support. If these conditions are not met, the element shall be
treated as if it were specified as optional support (unless otherwise stated).
i The element is outside the scope of this IO-ICS – i.e., it will not be the subject of an ICS
conformance test.
– in the given context the base Specification makes it impossible to use this capability.

A.4.3 Support column
This column shall be completed by the supplier or implementor to indicate the level of implementation of
each item. The proforma has been designed such that the only entries required in that column are:
Y Yes, the item has been implemented;

N No, the item has not been implemented;
– The item is not applicable.
In the IO-ICS Proforma tables, every leading items marked “m” should be supported by the IUT. Sub-
elements marked “m” should be supported if the corresponding leading feature is supported by the IUT.
All entries within the IO-ICS shall be made in ink. Alterations to such entries shall be made by crossing
out, not erasing nor making the original entry illegible, and writing the new entry alongside. All such
alterations to records shall be initialed by the staff making them.
A.4.4 Note Column
The "Note" column has to read as follows:
see xx(xx) Refers to table xx item xx.

Notexx Refers to Note xx.
pxx Refers to predicate xx.
A.4.5 Item column
Each row within the IO-ICS Proforma which requires implementation details to be entered is numbered in
a separate column. This numbering is included as a means of uniquely identifying all possible
implementation details within the IO-ICS Proforma.
A.4.6 Predicate definitions
If the classification of an Element of Service (EoS) or a Protocol Element is subject to a predicate,

support of the item is mandatory if the related predicate is true. Otherwise support of the item is
optional.
Within this appendix, predicates are clearly defined where:
p1 Copy Precedence EoS is supported. p5 ACP 127 Notifications Response EoS is

supported.
p2 Primary Precedence EoS is supported
p6 Authorizing Users Indication EoS is
p3 ACP 127 Message Identifier EoS is supported.
supported.
p7 Auto-forwarded Indication EoS is supported.
p4 ACP 127 Notification Request EoS is
supported. p8 Blind Copy Recipient Indication EoS is
supported.

p9 Codress Message Indicator EoS is supported. p27 Originator Reference EoS is supported.
p10 Corrections EoS is supported. p28 Originator PLAD EoS is supported.
p11 Cross-referencing Indication EoS is p29 Other Recipient Indicator EoS is supported.
supported.
p30 Pilot Forwarded EoS is supported.
p12 Distribution Code EoS is supported.
p31 Primary and Copy Recipients Indication EoS
p13 Exempted Addresses EoS is supported. is supported.
p14 Expiry Date Indication EoS is supported. p32 Receipt Notification Request Indication EoS
is supported.
p15 Extended Authorization Info EoS is
supported. p33 Reply Request Indication EoS is supported.
p16 Forwarded Message Indication EoS is p34 Replying Message Indication EoS is
supported. supported.
p17 Handling Instructions EoS is supported. p35 Sensitivity Indication EoS is supported.
p18 Importance Indication EoS is supported. p36 Use of Address List EoS is supported.
p19 Incomplete Copy Indication EoS is supported. p37 If the implementation can originate a request
for Receipt or Non-receipt Notifications, then
p20 Language Indication EoS is supported. it is mandatory to support receipt of the MN
PDU, else it is optional.
p21 Message Instructions EoS is supported.
p38 If any of the conditions for Non-receipt can
p22 Message Type EoS is supported. occur, all the related fields need to be
generatable.
p23 Multi-part Body Indication EoS is supported. p39 If auto-forwarding is supported, the related
fields in an NRN must be supported.
p24 Non-receipt Notification Request Indication
EoS is supported. p40 If any of the subsidiary MM-specific
parameters are supported then m, else o.
p25 Obsoleting Indication EoS is supported.
p41 If any of the heading-extensions are
p26 Originator Indication EoS is supported. supported then support of this element is m,
else support is o.
A.5 Capabilities and Options
The following tables list the detailed requirements for MM implementations.

A.5.1 Supported Options
Item Question Base Support Comments
1 Are all mandatory requirements of the o

FMH11(D) profile implemented?


4 Are all mandatory requirements of the ACP 127 o

Interworking (ACP127) FG implemented, as
defined in FMH11(D)?
A.5.2 MM EoS
A.5.2.1 Basic MM EoS
Item Element Base Support Notes
Orig. Rec. Orig. Rec.
1 Copy Precedence o o
2 MM-message Identification m m
3 Primary Precedence o o
4 Subject Indication m m
5 Typed Body m m
A.5.2.2 Optional MM EoS
Item Element of Service Base Support Notes
1 ACP127 Message Identifier o o
2 ACP127 Notification Request o o
3 ACP127 Notification Response o o
4 Authorizing Users Indication o o
5 Auto-forwarded Indication o m
6 Blind Copy Recipient Indication o o
7 Body Part Encryption Indication o o
8 Clear Service o o
9 Codress Message indicator o o
10 Corrections o o
11 Cross-referencing Indication o o
12 Distribution Code o o

UNCLASSIFIED B - 10 ORIGINAL
Item Element of Service Base Support Notes
13 Exempted Addresses o o
14 Expiry Date Indication o o
15 Extended Authorization Info o o
16 Forwarded Message Indication o o
17 Handling Instructions o o
18 Importance Indication o o
19 Incomplete Copy Indication o o
20 Language Indication o o
21 Message Instructions o o
22 Message Type o o
23 Multi-part Body Indication o o
24 Non-receipt Notification Request o o

Indication
25 Obsoleting Indication o o
26 Originator Indication o o
27 Originator Reference o o
28 Originator PLAD o o
29 Other Recipient Indicator o o
30 Pilot Forwarded o o
31 Primary and Copy Recipients m m

Indication
32 Receipt Notification Request Indication o o
33 Reply Request Indication o o
34 Replying Message Indication m m
35 Sensitivity Indication o o
36 Use of Address List o o

A.5.3 Supported information objects
1 Military Message (MM) m m
1.1 heading m m see A.5.3.1
1.2 body m m see A.5.3.2
2 Military Notification (MN) m c p37, Note 1, see

A.5.3.3
Note:
1 If the conditions for which a Non-receipt Notification would be generated are not supported, the ability to generate a Non-
Receipt Notification is optional.
A.5.3.1 MM heading fields
1 this-IPM m m see A.5.3.4(3)
2 originator m m see A.5.3.4(2)
3 authorizing-users c m p6, see A.5.3.4(2)
4 primary-recipients m m see A.5.3.4(1)
5 copy-recipients m m see A.5.3.4(1)
6 blind-copy-recipients c m p8, see A.5.3.4(1)
7 replied-to-IPM m m p34, see A.5.3.4(3)
8 obsoleted-IPMs c m p25, see A.5.3.4(3)
9 related-IPMs c m p11, see A.5.3.4(3)
10 subject m m
11 expiry-time c m p14
12 reply-time c m p33
13 reply-recipients c m p33, see A.5.3.4(2)
14 importance c m p18
15 sensitivity c m p35
16 auto-forwarded c m p7, Note 1
17 extensions c m p41
17.1 incomplete-copy c c p19
17.2 languages c m p20
17.3 primary-precedence c c p2, see A.5.3.4(4)
17.4 copy-precedence c c p1, see A.5.3.4(4)

17.5 message-type c c p22
17.5.1 type m m
17.5.2 identifier o m
17.6 address-list-indicator c c p36, see A.5.3.4(2)
17.6.1 type o m
17.6.2 list-name o m
17.6.3 notification-request o m
17.6.4 reply-request o m
17.7 exempted-address c c p13, see A.5.3.4(2)
17.8 extended-authorisation-info c c p15
17.9 distribution-codes c c p12
17.9.1 sics m m
17.9.2 dist-extensions o m
17.10 message-instructions c c p21
17.11 codress-message o c p9
17.12 originator-reference c c p27
17.13 other-recipient-indicator c c p29
17.13.1 type m m
17.13.2 designator m m
17.14 handling-instructions o c p17
17.15 pilot-forwarding-info o c p30
17.15.1 pilot-precedence o m see A.5.3.4(4)
17.15.2 pilot-recipient o m
17.15.3 pilot-security o m
17.15.4 pilot-handling o m
17.16 acp127-message-identifier o c p3
17.17 originator-plad o c p28
Note:
1 Support for Auto-forwarding is dependent on national or local policy and may be influenced by security procedures.
Note: The additional heading extension body-part-security-label may be added here subject to approval of a pending change proposal
to STANAG 4406.

A.5.3.2 MM body
1 ia5-text o o see ISO/IEC 10021-7
1.1 parameters m m
1.1.1 repertoire o m
1.2 data m m
2 voice o o see ISO/IEC 10021-7
2.1 parameters m m
2.2 data m m
3 g3-facsimile o o see ISO/IEC 10021-7
3.1 parameters m m
3.1.1 number-of-pages o o
3.1.2 non-basic-parameters o o
3.1.2.1 two-dimensional o o
3.1.2.2 fine-resolution o o
3.1.2.3 unlimited-length o o
3.1.2.4 b4-length o o
3.1.2.5 a3-width o o
3.1.2.6 b4-width o o
3.1.2.7 uncompressed o o
3.2 data m m
4 g4-class-1 o o see ISO/IEC 10021-7
5 teletex o o see ISO/IEC 10021-7
5.1 parameters m m
5.1.1 number-of-pages o o
5.1.2 telex-compatible o m
5.1.3 non-basic-parameters o o
5.2 data m m
6 videotex o o see ISO/IEC 10021-7
6.1 parameters m m
6.1.1 syntax o o
6.2 data m m
7 encrypted o o see ISO/IEC 10021-7
7.1 parameters m m
7.2 data m m

8 message o o see ISO/IEC 10021-7
8.1 parameters m m
8.1.1 delivery-time o o
8.1.2 delivery-envelope o o
8.2 data m m
8.2.1 IPM m m
9 mixed-mode o o see ISO/IEC 10021-7
10 bilaterally-defined o o see ISO/IEC 10021-7
11 nationally-defined o o see ISO/IEC 10021-7
12 externally-defined o o see A.5.3.2.1
A.5.3.2.1 Extended body part support
1 ia5-text-body-part o o see A.5.3.2(1)
2 g3-facsimilie-body-part o o see A.5.3.2(3)
3 g4-class1-body-part o o see A.5.3.2(4)
4 teletex-body-part o o see A.5.3.2(5)
5 videotex-body-part o o see A.5.3.2(6)
6 encrypted-body-part o o
6.1 parameters o m
6.2 data m m
7 message-body-part c c p16, see A.5.3.2(5)
8 mixed-mode-body-part o o
9 bilaterally-defined-body-part o o
10 nationally-defined-body-part o o
11 general-text o o
12 file-transfer-body-part o o see A.5.3.2.2
13 voice-body-part o o
13.1 parameters o m
13.2 data m m
14 oda-body-part o o see ISO/IEC 8613-1

15 adatp3-body-part o o
15.1 parameters o m
15.2 data m m
16 corrections-body-part o c p10
16.1 parameters o m
16.2 data o m
17 forwarded-encrypted-body-part o o
17.1 parameters o m
17.1.1 delivery-time o m
17.1.2 delivery-envelope m m
17.2 data m m
18 mm-message-body-part c c p16
18.1 parameters o m
18.1.1 delivery-time o m
18.2 data m m see A.5.3(1)
19 acp127data-body-part o o
19.1 parameters o m
19.2 data o m
20 forwarded-CSP-Message-Body-Part o o
Note: The additional body parts forwarded-report-body-part, forwarded-notification-body-part, and server-query-body-part may be
added here subject to approval of a pending change proposal to STANAG 4406.
A.5.3.2.2 General text repertoire support
Item Repertoire set description Repetoire Profile Support Comments

identifier(s)
1 Basic (ISO 646) {1,6} o o
2 Basic-1 (ISO 8859-1) {1,6,100} o o
3 Basic + Chinese (1) {1,6,58} o o
5 Basic + Japanese (1) {1,6,13,87} o o
7 Basic + Korean {1,6,149} o o
8 Basic-1 + Cyrillic (ISO 8859-5) {1,6,100,144} o o

Item Repertoire set description Repetoire Profile Support Comments

identifier(s)
9 Basic-1 + Arabic (ISO 8859-6) {1,6,100,127} o o
10 Basic-1 + Greek (ISO 8859-7) {1,6,100,126} o o
11 Basic-1 + Hebrew (ISO 8859-8) {1,6,100,138} o o
12 Full Latin (1) {1,6,100,154} o o
13 Full Latin (2) (ISO 6937) {1,6,156} o o
14 Teletex Basic Latin (T.61) {102,103,106,107) o o
A.5.3.3 MN fields
1 subject-IPM m m
2 ipn-originator c m p26
3 IPM-preferred-recipient m m
4 conversion-eits o m
5 notification-extensions o o
6 non-receipt-fields c c p38
6.1 non-receipt-reason m m
6.2 discard-reason m m
6.3 auto-forward-comment c m p39
6.4 returned-IPM o o
6.5 nrn-extensions o o
7 receipt-fields o o
7.1 receipt-time m m
7.2 acknowledgment-mode o m
7.2.1 manual m m
7.2.2 automatic o m
7.3 suppl-receipt-info o o
7.4 rn-extensions o o

8 other-notification-type-fields o c p5
8.1 acp127-notification-response o c p5
8.1.1 acp127-notification-type o m
8.1.2 receipt-time o m
8.1.3 addressListInicator o m
8.1.4 acp127-recipient o m
8.1.5 acp127-supp-info o m
A.5.3.4 Common data types
1 RecipientSpecifier
1.1 recipient m m see A.5.3.4(2)
1.2 notification-requests c m p32, p34
1.2.1 rn c m p32
1.2.2 nrn c m p24
1.2.3 IPM-return o o
1.3 reply-requested c m p33
1.4 recipient-extensions c o p4
1.4.1 acp127-notification-request c o p4
2 ORDescriptor
2.1 formal-name m m see A.5.3.4(5)
2.2 free-form-name c c p26
2.3 telephone-number o o
3 MMIdentifier
3.1 user m m see A.5.3.4(5)
3.2 user-relative-identifier m m
4 MMHSPrecedence
4.1 deferred (0) o m
4.2 routine (1) m m
4.3 priority (2) m m
4.4 immediate (3) m m

4.5 flash (4) m m
4.6 override (5) o m
4.7 nato-reserved (6-15) i i
4.8 nationally defined (16-30) i i
5 ORName
5.1 mnemonic O/R address m m
5.2 numeric O/R address m m
5.3 terminal O/R address o o
5.4 formatted postal O/R address o o
5.5 unformatted postal O/R address o o
5.6 directory-name m m
A.6 Message Store Attributes
This section classifies MM-specific MS attributes and applies to both the UA an MS.
Item Attribute Base Support Notes
1 acknowledgment-mode o
2 authorizing-users o
3 auto-forward-comment o
4 auto-forwarded o
5 bilaterally-defined-body-parts o
6 blind-copy-recipients o
7 body m
8 conversion-eits o
9 copy-recipients o
10 discard-reason o
11 encrypted-body-parts o
12 encrypted-data o
13 encrypted-parameters o
14 expiry-time o
15 extended-body-part-types o
16 g3-facsimile-body-parts o
17 g3-facsimile-data o
18 g3-facsimile-parameters o

19 g4-class1-body-parts o
20 heading m
21 ia5-text-body-parts o
22 ia5-text-data o
23 ia5-text-parameters o
24 importance o
25 incomplete-copy o
26 ipm-entry-type m
27 ipm-preferred-recipient o
28 ipm-synopsis o
29 ipn-originator o
30 languages o
31 message-body-parts o
32 message-data o
33 message-parameters o
34 mixed-mode-body-parts o
35 nationally-defined-body-parts o
36 non-receipt-reason o
37 nrn-requestors o
38 obsoleted-ipms o
39 originator o
40 primary-recipients o
41 receipt-time o
42 related-ipms o
43 replied-to-ipm o
44 reply-recipients o
45 reply-requestors o
46 reply-time o
47 returned-ipm o
48 rn-requestors o
49 sensitivity o
50 subject o
51 subject-ipm m
52 suppl-receipt-info o
53 teletex-body-parts o

54 teletex-data o
55 teletex-parameters o
56 this-ipm m
57 videotex-body-parts o
58 videotex-data o
59 videotex-parameters o
60 voice-body-parts o
61 voice-data o
62 voice-parameters o
63 acp127-message-identifier o
64 address-list-indicator o
65 codress-message o
66 copy-precedence o
67 distribution-codes o
68 exempted-address o
69 extended-authorisation-info o
70 handling-instructions o
71 message-instructions o
72 message-type o
73 originator-reference o
74 originator-plad o
75 other-recipients-indicator o
76 pilot-forwarding-info o
77 primary-precedence o
78 acp127-notificaiton-request o
79 acp127-receipt-response o
A.7 AutoForwardRegistrationParameter
4 other-parameters c c p40
4.1 auto-forwarding-comment o o
4.2 cover-note o o
4.3 this-ipm-prefix o o

A.8 Other information
A.8.1 Elements of Service support
The following tables shall be completed to indicate (Y or √ ), for each MM, MT, MH/PD, and MS Element
of Service, whether the EoS is made available to the MHS user and, if so, how this is achieved. For
each EoS for which support is claimed, the implementor will check the column which indicates how the
EoS is supported in a given instance. Where suport for origination and reception cannot be covered by a
single indication, then both shall be indicated. If appropriate the Comments column can be filled in to
provide additional information as to how the EoS is selected.
The columns have the following meanings:
Service the EoS can be dynamically selected by the MHS user (i.e. for invocation and/or
notification, as appropriate) without requiring reconfiguration of the UA or other
intervention in each instance (whether the semantics of the EoS are available at a
human user interface, programmatic interface or by other means may be specified in the
Comments column)
Auto the EoS is automatically invoked/actioned by the UA without reference to the MHS user
(whether selection is dynamically determined based on some other knowledge or criteria
may be specified in the Comments column)
Config the UA may be configured to select the EoS by the execution of some off-line process
Other any other means of using the EoS
A.8.1.1 MM Elements of Service support
Ref Element of Service Service Auto Config Comments/Other
1 ACP127 Message Identifier
2 ACP127 Notification Request
3 ACP127 Notification Response
4 Authorizing Users Indication
5 Auto-forwarded Indication
6 Blind Copy Recipient Indication
7 Body Part Encryption Indication
8 Clear Service
9 Codress Message indicator
10 Copy Precedence
11 Corrections
12 Cross-referencing Indication
13 Distribution Code
14 Exempted Addresses

15 Expiry Date Indication
16 Extended Authorization Info
17 Forwarded Message Indication
18 Handling Instructions
19 Importance Indication
20 Incomplete Copy Indication
21 Language Indication
22 Message Instructions
23 Message Type
24 IPM-message Identification
25 Multi-part Body
26 Non-receipt Notification Request

Indication
27 Obsoleting Indication
28 Originator Indication
29 Originator Reference
30 Originator PLAD
31 Other Recipient Indicator
32 Pilot Forwarded
33 Primary and Copy Recipients

Indication
34 Primary Precedence
35 Receipt Notification Request

Indication
36 Reply Request Indication
37 Replying Message Indication
38 Sensitivity Indication
39 Subject Indication
40 Typed Body
41 Use of Address List

A.8.1.2 MM Elements of Service support
1 Access Management
2 Alternate Recipient Allowed
3 Alternate Recipient Assignment
4 Content Confidentiality
5 Content Integrity
6 Content Type Indication
7 Conversion Prohibition
8 Conversion Prohibition in Case of

Loss of Information
9 Converted Indication
10 Deferred Delivery
11 Deferred Delivery Cancellation
12 Delivery Notification
13 Delivery Time Stamp Indication
14 Designation of Recipient by
Directory Name
15 Disclosure of Other Recipients
16 DL Expansion History Indication
17 DL Expansion Prohibited
18 Explicit Conversion
19 Grade of Delivery Selection
20 Hold for Delivery
21 Implicit Conversion
22 Latest Delivery Designation
23 Message Flow Confidentiality
24 Message Identification
25 Message Origin Authentication
26 Message Security Labelling
27 Message Sequence Integrity
28 Multi-Destination Delivery
29 Non-delivery Notification
30 Non-repudiation of Delivery
31 Non-repudiation of Origin
32 Non-repudiation of Submission
33 Original Encoded Information Types

Indication

34 Originator Requested Alternate

Recipient
35 Prevention of Non-delivery
Notification
36 Probe
37 Probe Origin Authentication
38 Proof of Delivery
39 Proof of Submission
40 Redirection Disallowed by Originator
41 Redirection of Incoming Messages
42 Report Origin Authentication
43 Requested Preferred Delivery

Method
44 Restricted Delivery
45 Return of Content
46 Secure Access Management
47 Submission Time Stamp Indication
48 Use of Distribution List
49 User/UA Capabilities Registration
A.8.1.3 MH/PD Elements of Service support
1 Additional Physical Rendition
2 Basic Physical Rendition
3 Counter Collection
4 Counter Collection with Advice
5 Delivery via Bureaufax Service
6 EMS (Express Mail Service)
7 Ordinary Mail
8 Physical Delivery Notification by

MHS
9 Physical Delivery Notification by

PDS
10 Physical Forwarding Allowed
11 Physical Forwarding Prohibited
12 Registered Mail

13 Registered Mail to Addresses in

Person
14 Request for Forwarding Address
15 Special Delivery
16 Undeliverable Mail with Return of

Physical Message
A.8.1.4 MS Elements of Service support
1 MS Register
2 Stored Message Alert
3 Stored Message Auto-forward
4 Stored Message Deletion
5 Stored Message Fetching
6 Stored Message Listing
7 Stored Message Summary
A.8.2 Encoded information type conversion requests supported
The following table shall be completed if support of the MM Conversion FG is claimed, to indicate (Y or
√) which encoded information type conversions the implementation can request (see clause 7.1 of
AMH2n(D) Part 1).
Item Encoded Information Type Conversion Supported Comments

(Y/N)
1.1 ia5-text-to-teletex (0)
1.2 ia5-text-to-g3-facsimile (8)
1.3 ia5-text-to-g4-class-1 (9)
1.4 ia5-text-to-videotex (10)
1.5 teletex-to-ia5-text (11)
1.6 teletex-to-g3-facsimile (12)
1.7 teletex-to-g4-class-1 (13)
1.8 teletex-to-videotex (14)
1.9 videotex-to-ia5-text (16)
1.10 videotex-to-teletex (17)

A.8.3 Non-standard integer body part types supported
The following table shall be completed to indicate (Y or √) which (if any) non-standard integer body part
types the implementation is capable of originating and/or receiving.
Item Body Part Type Orig. Rec. Comments
1 ODA (12)
2 ISO6937Text (13)
3 USA nationally-defined body part types (310)
4 JIS-1 (440)
5 other (specify)
A.8.4 Extended body part types supported
The following table shall be completed to indicate (Y or √) which (if any) specific extended body part
types the implementation is capable of originating and/or receiving (in addition to those specified in
A.5.3.2.1), and the object identifier value(s) supported in each case.
Item Extended Body Part Type Orig. Rec. Object Identifier Value(s)
It should be indicated below whether the implementation can be configured to allow other externally-
defined body part types to be used, and how this is achieved.

A.8.5 General text body part repertoire support
The following table shall be completed to indicate (Y or √) which specific character repertoires the
implementation is capable of originating and/or receiving for support of the general-text body part type.
It shall be stated in the Comments column how such capability is implemented.
NOTE - The table identifies some useful repertoire sets as proposed by the three regional workshops, but
this should not be seen as a comprehensive list. Repertoire set {1,6} is considered to be the minimum
support level. It is expected that the European and North American regional profiles will also require
support of repertoire set {1,6,100}.
Item Repertoire set description Repertoire Orig. Rec. Comments

identifier(s)

Appendix B
(normative)
Technical corrigenda
International Standards are subject to constant review and revision by the ISO/IEC Technical
Committees concerned. The following amendments and corrigenda are approved by ISO/IEC JTC1 and
are considered as normative references in this part of ACP 123.
NOTE - Corresponding corrigenda to the equivalent CCITT Recommendations are contained in the joint CCITT/ISO
MHS Implementor's Guide Version 11.
ISO/IEC 10021-1/Cor.1:1991
ISO/IEC 10021-1/Cor.2:1991
ISO/IEC 10021-1/Cor.3:1992
ISO/IEC 10021-1/Cor.4:1992
ISO/IEC 10021-1/Cor.5:1992
ISO/IEC 10021-1/Cor.6:1994
ISO/IEC 10021-1/Cor.7:1994
ISO/IEC 10021-2/Cor.1:1991
ISO/IEC 10021-2/Cor.2:1991
ISO/IEC 10021-2/Cor.3:1992
ISO/IEC 10021-2/Cor.4:1992
ISO/IEC 10021-2/Cor.5:1993
ISO/IEC 10021-2/Cor.6:1994
ISO/IEC 10021-2/Cor.7:1994
ISO/IEC 10021-7/Cor.1:1991
ISO/IEC 10021-7/Cor.2:1991
ISO/IEC 10021-7/Cor.3:1992
ISO/IEC 10021-7/Cor.4:1992
ISO/IEC 10021-7/Cor.5:1992
ISO/IEC 10021-7/Cor.6:1993
ISO/IEC 10021-7/Cor.7:1994
ISO/IEC 10021-7/Cor.8:1994
ISO/IEC 10021-7/Cor.9:1994
(Appendix B to Annex B)
(Appendix B to Annex B)
UNCLASSIFIED ANNEX C to ACP 123
ANNEX C
Standardized Profile
TITLE: Information technology – Standardized Profiles AMH1n(D) –

Military Message Handling Systems – Common Unrestricted Messaging
Part 1: MHS Service Support
SOURCE: ACP 123 Editor
STATUS: Draft text, 1997-08-15
This document forms part of a multipart Standardized Profile (SP) for Common Unrestricted
Messaging for Military Message Handling Systems (MMHS). It is outside the scope of the
current Taxonomy Framework for International Standardized Profiles (ISP). This SP is a
delta to the Civilian MHS Common Messaging ISP 10611 and includes only the additional
requirements for the MMHS. This document is content-type independent.
(Part 1 of Annex C)
UNCLASSIFIED C-1 ORIGINAL
Introduction
This Standardized Profile (SP) is defined within the context of functional standardization, in accordance
with the principles specified by ISO/IEC TR 10000, “Framework and Taxonomy of International
Standardized Profiles”. The context of functional standardization is one part of the overall field of
Information Technology (IT) standardization activities – covering base standards, profiles, and
registration mechanisms. A profile defines a combination of base standards that collectively perform a
specific well-defined IT function. Profiles standardize the use of options and other variations in the base
standards to promote system interoperability and to provide a basis for the development of uniform,
internationally recognized system tests.
One of the most important roles for a SP is to serve as the basis for the development of recognized
tests. SPs also guide implementors in developing systems that fit the needs of the MMHS. SPs are
produced not simply to ‘legitimize’ a particular choice of base standards and options, but to promote real
system interoperability. The development and widespread acceptance of tests based on this and other
SPs is crucial to the successful realization of this goal.
This part of AMH1n(D) provides a functional description and specification of MMHS service support and
associated functionality as covered by the AMH1n(D) set of profiles. It identifies what additional service
support and functionality can be supported by each type of MHS component in a Military Messaging
environment (i.e., covering the services supported by an MM-UA, plus any additional MTA and MM-MS
aspects), divided into basic requirements and zero or more optional functional groups. Such
specifications are in many cases applicable to more than one MHS protocol or are otherwise concerned
with component functionality which although it can be verified via protocol, is not just related to protocol
support. The specification of this part is therefore designed for reference by the following parts (which
specify conformance requirements by protocol for each MHS component) and is additional to the
protocol-specific requirements specified in those parts. Thus, although this part contains normative
requirements, there is no separate conformance to this part (i.e., it is not identified in the MHS
taxonomy) since such requirements are only significant when referenced in the context of a particular
protocol profile.
This part of AMH1n(D) contains one normative appendix:
Appendix A Elements of Service for ACP 123
(Part 1 of Annex C)
Information technology – Standardized Profiles AMH1n(D) –

Military Message Handling Systems – Common Unrestricted
Messaging
Part 1 : MHS Service Support
1 Scope
1.1 General
This part of AMH1n(D) contains the overall specifications of the support of MHS Elements of Service and
other aspects of MHS functionality which are specific to the Military Message Handling System (MMHS)
which are generally not appropriate for consideration only from the perspective of a single MHS protocol.
These specifications form part of the Common Unrestricted Messaging application functions, as defined
in the parts of AMH1n(D), and are based on the Common Messaging content type-independent
specifications in ISO/IEC ISP 10611. Such specifications are in many cases applicable to more than one
MHS protocol or are otherwise concerned with component functionality which, although it can be verified
via protocol, is not just related to protocol support. They are therefore designed to be referenced in the
Common Unrestricted Messaging application profiles AMH1n(D) Part 2 (Specification of ROSE, RTSE,
ACSE, Presentation and Session Protocols for use by MMHS), AMH1n(D) Part 3 (AMH11(D)),
AMH1n(D) Part 4 (AMH12(D)) and AMH1n(D) Part 5 (AMH13(D)), which specify the support of specific
MHS protocols and associated functionality.
This SP makes use of the Common Messaging AMH1. It specifies the additional requirements needed
to support the MMHS Common Unrestricted Messaging environment.
The specifications in this part of AMH1n(D) are divided into basic requirements, which are required to
be supported by all MMHS implementations claiming conformance to this profile, and a number of
optional functional groups, which cover significant discrete areas of related functionality which are not
required to be supported by all implementations.
1.2 Position within the taxonomy
This part of AMH1n(D) is the first part, as common text, of a multipart SP for AMH1n(D) Military
Message Handling Systems. The multipart SP consists of the following parts:
Part 1 – MHS Service Support

Part 2 – Specification of ROSE, RTSE, ACSE, Presentation and Session Protocols for use by MMHS
Part 3 – AMH11(D) – MMHS Requirements for Message Transfer (P1)
Part 4 – AMH12(D) – MMHS Requirements for MTS Access (P3)
Part 5 – AMH13(D) – MMHS Requirements for MS Access (P7)
This part of AMH1n(D) does not, on its own, specify any profiles.
This SP must be combined with the multipart ISP identified in ISO/IEC TR 10000-2 as “AMH1, Message
Handling Systems – Common Messaging” (see also ISO/IEC TR 10000–1, 8.2 for the definition of
multipart ISPs).
(Part 1 of Annex C)
The multipart AMH1 ISP consists of the following parts:
Part 1 – MHS Service Support

Part 2 – Specification of ROSE, RTSE, ACSE, Presentation and Session Protocols for use by MHS
Part 3 – AMH11 – Message Transfer (P1)
Part 4 – AMH12 – MTS Access (P3)
Part 5 – AMH13 – MS Access (P7)
It may be combined with any approved T-Profiles (see ISO/IEC TR 10000) specifying the OSI
connection-mode Transport service.
2 References
The following documents are additional documents referenced to those cited in ISO/IEC 10611-1.
this part of AMH1n(D). At the time of publication, the editions indicated were valid. All documents are
subject to revision, and parties to agreements based on this part of AMH1n(D) are warned against
automatically applying any more recent editions of the documents listed below, since the nature of
references made by SPs to such documents is that they may be specific to a particular edition.
Members of IEC and ISO maintain registers of currently valid International Standards and ISPs, and
CCITT maintains published editions of its current Recommendations.
Technical corrigenda to the base standards referenced are listed in appendix B of ISO/IEC 10611-1.
NOTE – References in the body of this part of AMH1n(D) to specific clauses of ISO/IEC documents shall
be considered to refer also to the corresponding clauses of the equivalent CCITT Recommendations (as
noted below) unless otherwise stated.
ACP 123: Common Messaging Strategy and Procedures, November 1994.
ISO/IEC 10611-1: 1994, Information technology – International Standardized Profiles – Message

Handling Systems – Common Messaging – Part 1: MHS Service Support.
ISO/IEC 10021-1:1990/Am.2, Information technology – Message-Oriented Text Interchange System

(MOTIS) – Part 1: System and Service Overview, Amendment 1 Message Store Extensions 1994.

(MOTIS) – Part 2: Overall Architecture; Amendment 1: Representation of O/R Addresses for Human
Exchange 1994.

(MOTIS) – Part 2: Overall Architecture; Amendment 2: Minor Enhancements: Multinational Organizations
and Terminal-form Addresses 1994.

(MOTIS) – Part 4: Message Transfer System: Abstract Service Definition and Procedures; Amendment 1:
Minor Enhancements: Notification-type and Directory Substitution 1994.
(Part 1 of Annex C)
MHS Implementors' Guide, Version 11, July 1994 (ITU-T Special Rapporteur's Group on Message
Handling Systems and ISO/IEC JTC1/SC18/WG4 SWG on Messaging).
(Application for copies of these documents should be addressed to the American National Standards
Institute, 11 West 42nd Street, NY, NY 10036 or to ISO, Van Demonstrate 94, 1013 CN Amsterdam,
Netherlands.)
3 Definitions
For the purposes of this part of AMH1n(D), the following definitions apply.
Terms used in this part of AMH1n(D) are as defined in the referenced base standards, and in ISO/IEC
10611-1.
3.3 Profile object identifiers
No additional requirements.
4 Abbreviations and Acronyms
The following are additional abbreviations and acronyms to those defined in ISO/IEC ISP 10611-1.

ACSE Association Control Service Element
CCITT International Telegraph and Telephone Consultative Committee
CSP Common Security Protocol
DDA Domain Defined Attributes
EMS Express Mail Service
IEC International Electrotechnical Commission
ISO International Standards Organization
IT Information Technology
ITU International Telecommunication Union
ITU-T ITU Telecommunication Standardization Sector
JTC1 Joint Technical Committee
MH Message Handling
MM Military Message
NATO North Atlantic Treaty Organization
P1 MTS Transfer Protocol
P3 MTS Access Protocol
P7 MS Access Protocol
P772 MMS Protocol
PDS Physical Delivery System
ROSE Remote Operations Service Element
RTSE Reliable Transfer Service Element
SC Sub committee
(Part 1 of Annex C)
SP Standardized Profiles
SPICS Standardized Profiles Implementation Conformance Statement
STANAG Standardization Agreement
SWG Special Working Group
Support level for Elements of Service (see 3.2):
m mandatory support
o optional support
c conditional support
i out of scope
– not applicable
x prohibited
5 Conformance
No conformance requirements are specified in this part of AMH1n(D).
NOTE – This part of AMH1n(D) is a reference specification of the basic requirements and functional
groups covered by the AMH1n(D) set of profiles and is additional to the protocol-specific requirements
specified in the following parts of this SP. Although this part of AMH1n(D) contains normative
requirements, there is no separate conformance to this part (i.e., it is not identified in the MHS
taxonomy) since such requirements are only significant when referenced in the context of a particular
protocol.
Conformance requirements are specified by protocol for each MHS component in the following parts of
AMH1n(D) with reference to the specifications in this part. Support of the functionality as specified in this
part may only be verifiable where the effect of implementation can be determined at a standardized
external interface -i.e. via a standard OSI communications protocol. Further, the provision of Elements
of Service and other functionality at a service interface will not necessarily be verifiable unless such
interface is realized in the form of a standard OSI communications protocol. Other forms of exposed
interface (such as a human user interface or a standardized API) may be provided, but are not required
for conformance to this version of AMH1n(D).
6 Basic requirements
Appendix A specifies the basic requirements for support of MHS Elements of Service (EoS) for
conformance to AMH1n(D) – i.e., the level of support required by all MMHS implementations, as
appropriate to each type of MHS component – i.e. MTA, MM-MS or MM-UA (as MTS-user or MS-user,
as relevant).
6.1 Content and encoded information types
It shall be stated in the ISPICS which content type and encoded information type values are supported.
6.2 Message Length
If the implementation imposes any constraints on the size of the message content or envelope, then all
such constraints shall be stated in the ISPICS.
(Part 1 of Annex C)
6.3 Number of Recipients
It shall be stated in the ISPICS if there is any limit on the number of recipients that can be specified in a
message envelope.
7 Functional groups
Appendix A also specifies any additional requirements for support of MHS EoS if support of an optional
functional group (FG) is claimed, as appropriate to each type of MHS component (i.e., MTA or MTS-
user). The following clauses summarize the functionality supported by each of the optional FGs and
identify any particular requirements or implementation considerations which are outside the scope of
formal conformance to AMH1n(D). A summary of the functional groups, identifying which may be
supported (Y) and which are not applicable (N) for each type of MHS component (i.e. MTA, MM-MS,
MM-UA - whether as MTS-user or as MS-user is not distinguished), is given in the following table.
Following the Y or N is an indication of the support classification (mandatory, optional, out of scope, or
prohibited) for the functional group in the context of this profile.
The following clauses summarize the functionality supported by each of the optional FGs and specifies
which FGs must be supported at the MTS level to support this SP.
Table 1 – Summary of AMH1n(D) optional functional groups

Functional Group MTA MS MM-UA
1
Conversion (CV) Y(o) N N
Distribution List (DL) Y(o) N N
Physical Delivery (PD) Y(o) N Y(o)

1
Redirection (RED) Y(m) N N
Latest Delivery (LD) Y(m) N N
Return of Contents (RoC) Y(x) Y(x) Y(x)
Security (SEC) Y(o) Y(o) N
Use of Directory (DIR) Y(m) N N

1
84 Interworking (84IW) Y(o) N N
ACP 127 Interworking (ACP127) N Y(o) Y(o)
Note:
1 MM-UA Functionality may be further defined in content type-dependent profiles.
7.1 Conversion (CV)
The Conversion FG covers support of those EoS which provide the functionality required to perform the
action of encoded information type conversion. Support of the CV FG is applicable to an MTA. Support
of the CV FG by an MTA covers support of the Explicit Conversion EoS only.
NOTE – Support of EoS associated with conversion prohibition is a basic MTA requirement, but this does
not imply a capability to perform conversion.
(Part 1 of Annex C)
An MTA implementation conforming to the CV FG shall conform to the Common Messaging CV FG as

specified in ISO/IEC ISP 10611 in the MMHS (i.e. the ability to perform conversion of MM content is
required).
7.2 Distribution List (DL)
Support for the Distribution List FG is optional in this SP.
An Implementation conforming to the DL FG shall conform to the Common Messaging DL FG as

specified in ISO/IEC ISP 10611. There are no additional requirements for an MTA in the MMHS.
7.3 Physical Delivery (PD)
The Physical Delivery FG is concerned with access to physical delivery (i.e. postal, courier, etc.)
services. The PD FG comprises two separate and distinct parts:
support of PD EoS on origination and submission;

support of a co-located physical delivery access unit (PDAU).
Support of PD EoS on submission is applicable for either an MTA or a UA. Support of a PDAU is only
applicable for an MTA.
An implementation conforming to the PD FG shall conform to the Common Messaging PD FG as

specified in ISO/IEC ISP 10611. An MM-UA conforming to the PD FG shall also make the PD EoS
available to the MMHS user for origination. There are no additional requirements for an MTA in the
MMHS.
7.4 Redirection (RED)
Support for the Redirection FG is mandatory.
An Implementation conforming to the RED FG shall conform to the Common Messaging RED FG as
7.5 Latest Delivery (LD)
Support for Latest Delivery FG for an MTA is mandatory in this SP.
An implementation conforming to the LD FG shall conform to the Common Messaging LD FG as

7.6 Return of Content (RoC)
Support for the Return of Content FG is prohibited for this SP.
(Part 1 of Annex C)
7.7 Security (SEC)
The Common Security Protocol (CSP) will provide the basic security for Messaging in the MMHS.
Therefore support for any of the classes in the Security FG as defined in the Common Messaging SEC
FG as specified in ISO/IEC ISP 10611 is optional in this SP.
For additional information about the Security classes and the Security FG see the Common Messaging
ISP 10611-1 MHS Service Support.
7.8 Use of Directory (DIR)
Support for the Directory FG is mandatory in this SP.
An implementation conforming to the DIR FG shall conform to the Common Messaging DIR FG as
7.9 84 Interworking (84IW)
Support for the 84 Interworking FG is optional in this SP.
An implementation conforming to the 84IW FG shall conform to the Common Messaging 84IW FG as
7.10 ACP 127 Interworking (ACP127)
The ACP 127 Interworking FG covers interworking between implementations conforming to MMHS and
the older messaging system following ACP 127 guidelines. Interworking takes place by way of a
gateway doing conversion between the two formats. However, if this FG is supported, the MMHS
implementation supports those optional services and protocol elements in P772 whose sole purpose is to
provide interworking for ACP 127 messages during the transition.
This FG requires support on reception for these services including User Interface display requirements.
These services even in the case of the FG will not be originated by the MM-UA but may instead be
added at the gateway during conversion and information returned with the gateway notification response.
It is recommended that support for this FG be a configurable option, so it may be turned off when no
longer required.
8 Naming and addressing
Support for numeric addresses and directory names is mandatory in addition to the naming and
addressing capabilities as specified in clause 8 of ISO/IEC ISP 10611-1. In addition, implementations
will support the Domain Defined Attributes (DDA) acp-plad and acp-ri for both origination and reception.
(Support of these DDAs to identify the MM-UA itself is not required.)
9 Error and exception handling
An implementation claiming conformance to the error and exception handling shall do so as specified in
ISO/IEC ISP 10611-1, clause 9.
(Part 1 of Annex C)
10 Content Type support
MTAs shall support transfer of content types independant of the content type. An implementation
claiming conformance to the this profile shall, at a minimum, support the transfer of the MM content type
indicated by id-mmhs-content OBJECT IDENTIFIER ::= { iso(1) identified-organizations(3) nato(26)
nato-standard(0) MMHS(4406) object-ids(0) content-type(4) mm88(1).
(Part 1 of Annex C)
UNCLASSIFIED C - 10 ORIGINAL
Appendix A
(normative)
ELEMENTS OF SERVICE FOR ACP 123

In the event of a discrepancy becoming apparent in the body of this part of AMH1n(D) and the tables in
this appendix, this appendix is to take precedence. Only the additional EoS requirements to those
defined in the Base (ISO/IEC 10611-1) and this SP are listed.
This appendix specifies the support constraints and characteristics of what shall or may appear in the
implementation columns of a IO-ICS of ACP 123. This appendix is broadly based on the current version
of ISO/IEC ISP for AMH1.
In each table, the "Basic" column reflects the level of support required for conformance to AMH1n(D) –
i.e. the minimum level of support required by all MTA, MM-MS, and MM-UA implementations supporting
this profile (see clause 6). The "Functional Group" column specifies any additional support requirements
if support of an optional functional group is claimed (see clause 7). Each column is then further
subdivided into support for origination ("Orig") and reception ("Rec".) as defined in clause 3.2, together
with the abbreviated name of the functional group ("FG") in the case of the second column. The
origination and reception columns are further subdivided to distinguish the support required for an MTA
from that for an MTS-user (the latter refers only to the use of MT services, not whether such services are
made available to the MHS user, and may be further qualified in a content type-dependent profile.
A.1 MT Elements of Service
Table A.1 – Elements of Service Belonging to The Basic MT Service
Elements of Service Basic Functional Group
Orig. Proc. Rec. FG Orig. Proc. Rec.
MTS- MTA MTA MTS- MTS- MTA MTA MTS-

user user user user
2
Content Type Indication
Notes:
2 At a minimum, an implementation must support the content type for MM (P772) which is identified by id-mmhs-content OBJECT
IDENTIFIER ::= { iso(1) identified-organization(3) nato(26) nato-standard(0) MMHS(4406) object-ids(0) content-type(4) mm88(1)}.
(Appendix A to Part 1 of Annex C)

Table A.2 – MT Service Optional User Facilities

user user user user
Alternate Recipient Allowed m m m m
Altnerate Recipient m
Assignment
14
Content Confidentiality
14
Content Integrity
Conversion Prohibition in
Case of Loss of Information
21
Deferred Delivery
17
Deferred Delivery c
21
Cancellation
Designation of Recipient by m m m
18
Directory Name
DL Expansion History m
Indication
Explicit Conversion CV m
15
Hold for Delivery c
Latest Delivery Designation m m m
Message Origin
14
Authentication
14
Message Security Labelling
19
Message Sequence Integrity
14
Non-repudiation of Delivery
14
Non-repudiation of Origin
Non-repudiation of
14
Submission
Originator Requested m m m
Alternate Recipient
20
Prevention of Non-delivery m
Notification
16 23
Probe ix x x
14
Probe Origin Authentication
14
Proof of Delivery
14
Proof of Submission
Redirection Disallowed by m m m
Originator
Redirection of Incoming m m m
Messages


user user user user
14
Report Origin Authentication
22
Return of Content ix x x
Secure Access Management m m m m m
Notes:
14 Support is according to the security class for which support is claimed – see clause A.1 of ISO/IEC ISP 10611-1. CSP will provide
the basic security for the MMHS. Therefore support for any of the classes in the Security FG is optional in this SP. Therefore the
SEC FG requirements are not enumerated in this table.
15 Support of the Hold for Delivery EoS is mandatory when using the P3 protocol. Implementation is a local matter in the case of a co-
located MTS-user and may be dependent on local policy.
16 Although support for Probes is required for MTAs in the base X.400 standard, it is recommended that support by MTS-users is not
required. This profile further makes Probes dynamically prohibited.
17 If Deferred Delivery is supported, Deferred Delivery Cancellation must also be supported.
18 Origination of the Designation of Recipient by Directory Name EoS implies (for those recipients who have been assigned Directory
Names in a Directory Service supported by the originating management domain) that the Directory Name may be specified for
recipients. Reception of this service implies display (to the user) of any Directory Names contained in the message.
19 Not part of SEC FG because it requires bilateral agreement to work.
20 The ability to request this service on a particular message may be dependent on the precedence requested.
21 Messages should be held in the originating MTA to provide support for Deferred Delivery and Deferred Delivery Cancellation.
22 Prohibition of this EoS means that bit 3 of the per-message-indicators envelope field shall be cleared (zero) and that bit 2 of the
notification-requests heading field shall be cleared. It implies that the returned-mm notification field shall never be originated.
23 Reception of Probe at the MTA will be logged as a security violation and no delivery or non-delivery report will be returned.
Table A.3 – Elements of Service Belonging to The Base MH/PD Service Intercommunication
MTS- MTA MTA PDAU MTS- MTA MTA PDAU

user user
Basic Physical Rendition _
Ordinary Mail _
Physical Forwarding Allowed _
Undeliverable Mail with Return _

of Physical Message

Table A.4 – Optional User Facilities for MH/PD Service Intercommunication
MTS- MTA MTA PDAU MTS- MTA MTA PDAU

user user
Additional Physical Rendition _
Counter Collection _
Counter Collection with Advice _
Delivery via Bureaufax Service _
EMS (Express Mail Service) _ PD m
Physical Delivery Notification _

by MHS
Physical Delivery Notification _

by PDS
Physical Forwarding _
Prohibited
Registered Mail _
Registered Mail to Addressee _

in Person
Request for Forwarding _

Address
Special Delivery _ PD m
Table A.5 – Security Services
A.2 MS Elements of Service
A Message Store is optional in the MMHS profiles, however, if one is implemented the following
Elements of Service apply.
The following tables specify additional requirements for support of MS EoS by an MM-MS and the
requirements for use of such services by an MS-user in the MMHS (i.e., an MM-UA) for conformance to
AMH1n(D).
In the following tables, the "Profile" column reflects the basic requirements for conformance to
AMH1n(D) - i.e. the minimum level of support required by all MM-UA and MM-MS implementations
conforming to this profile (see clause 6). The "Functional Group" column specifies any additional support
requirements if support of an optional functional group is claimed (see clause 7), together with the
abbreviated name of the functional group ("FG").

Table A.6 – Base Message Store
Elements of Service Profile Functional Group
UA MS FG UA MS
MS Register m
Stored Message Listing m
Stored Message Summary m
Table A.7 – MS Optional User Facilities
UA MS FG UA MS
Stored Message Alert m m
Stored Message Auto-forward m m
A.3 Additional Information
A.3.1 MT Elements of Service support
The tables in ACP 123, annex B, appendix A, clause A.8.1.2 and A.8.1.3, shall be completed to indicate,
for each MT Element of Service, whether it is available to the MHS user and, if so, how this is achieved.
For each EoS for which support is claimed, the implementor will check the column which indicates how
the EoS is supported in a given instance. If appropriate the Comments column can be filled in to provide
additional information as to how the EoS is selected.
ACP 123 goes beyond X.400 by stating which MT Elements of Service are to be supported as user
options and which have requirements for display at the user interface. If support for these are claimed,
the EoS must be selectable at the user interface for a given message. These requirements are indicated
with the following codes in the Profile column in the following table:
s the user must be able to select the service and its associated information on origination
D this information must be displayed to the user, if it is present
Table A.8 – MT Elements of Service support
Ref Element of Service Profile
1 Access Management
2 Alternate Recipient Allowed s
3 Alternate Recipient Assignment
4 Content Confidentiality
5 Content Integrity
6 Content Type Indication

7 Conversion Prohibition s
8 Conversion Prohibition in Case of Loss of Information s1
9 Converted Indication D
10 Deferred Delivery s
11 Deferred Delivery Cancellation s
12 Delivery Notification D
13 Delivery Time Stamp Indication D
14 Designation of Recipient by Directory Name sD
15 Disclosure of Other Recipients
16 DL Expansion History Indication D
17 DL Expansion Prohibited s
18 Explicit Conversion s
19 Grade of Delivery Selection
20 Hold for Delivery
21 Implicit Conversion
22 Latest Delivery Designation s
23 Message Flow Confidentiality
24 Message Identification
25 Message Origin Authentication
26 Message Security Labelling D2
27 Message Sequence Integrity
28 Multi-Destination Delivery s
29 Non-delivery Notification sD
30 Non-repudiation of Delivery
31 Non-repudiation of Origin
32 Non-repudiation of Submission
33 Original Encoded Information Types Indication
34 Originator Requested Alternate Recipient sD
35 Prevention of Non-delivery Notification s
36 Probe
37 Probe Origin Authentication
38 Proof of Delivery
39 Proof of Submission
40 Redirection Disallowed by Originator s
41 Redirection of Incoming Messages s
42 Report Origin Authentication

43 Requested Preferred Delivery Method
44 Restricted Delivery
45 Return of Content
46 Secure Access Management
47 Submission Time Stamp Indication D
48 Use of Distribution List s
49 User/UA Capabilities Registration
Notes:
1 If Explicit Conversion is supported the user shall have the ability to select this service.
2 Note that this is the X.400 provided service rather than any nationally defined security
mechanism. This classification is not intended to imply any requirement to originate or
understand the semantics of this security label.
Table A.9 – MH/PD Elements of Service support
1 Additional Physical Rendition
2 Basic Physical Rendition
3 Counter Collection
4 Counter Collection with Advice
5 Delivery via Bureaufax Service
6 EMS (Express Mail Service)
7 Ordinary Mail
8 Physical Delivery Notification by MHS
9 Physical Delivery Notification by PDS
10 Physical Forwarding Allowed
11 Physical Forwarding Prohibited
12 Registered Mail
13 Registered Mail to Addresses in Person
14 Request for Forwarding Address
15 Special Delivery
16 Undeliverable Mail with Return of Physical Message
A.3.2 MS Elements of Service support
The table in ACP 123, annex B, appendix A, clause A.8.1.4, shall be completed to indicate, for each MS
Element of Service, whether it is available to the MHS user and, if so, how this is achieved. For each
EoS for which support is claimed, the implementor will check the column which indicates how the EoS is
supported in a given instance. If appropriate the Comments column can be filled in to provide additional
information as to how the EoS is selected.

ACP 123 goes beyond X.400 by stating which MS Elements of Service are to be supported as user
Table A.10 – MS Elements of Service support
1 MS Register
2 Stored Message Alert s
3 Stored Message Auto-forward s
4 Stored Message Deletion s
5 Stored Message Fetching s
6 Stored Message Listing s
7 Stored Message Summary s

TITLE: Information technology Standardized Profiles AMH1n(D) –

Military Message Handling Systems – Common Unrestricted Messaging –
Part 2: Specification of ROSE, RTSE, ACSE, Presentation and Session Protocols for use by
MMHS
(Part 2 of Annex C)
Introduction
This part of AMH1n(D) specifies how the Remote Operations Service Element, the Reliable Transfer
Service Element, the Association Control Service Element, the Presentation Layer, and the Session
Layer standards shall be used to provide the required OSI upper layer functions for MMHS. The text for
this SP is based on ISO/IEC ISP 10611.
This part of AMH1n(D) contains three normative appendices:
Appendix A SPICS Requirements List – Specific Upper Layer Requirements for ACSE,
Presentation and Session
Appendix B SPICS Requirements List for RTSE
Appendix C SPICS Requirements List for ROSE
(Part 2 of Annex C)

Messaging
Part 2 : Specification of ROSE, RTSE, ACSE, Presentation
and Session Protocols for use by MMHS
1 Scope
1.1 General
This part of AMH1n(D) specifies how the Remote Operations Service Element (ROSE), the Reliable
Transfer Service Element (RTSE), the Association Control Service Element (ACSE), the Presentation
Layer, and the Session Layer standards shall be used to provide the required OSI upper layer functions
for MMHS (see also figure 1). These specifications are therefore the common basis for the MMHS
application functions, as defined in the other parts of AMH1n(D), and for content type-dependent SPs for
MHS that will be developed.
This part of AMH1n(D) is the second part of a multipart SP for AMH1n(D) Military Message Handling
Systems – Common Unrestricted Messaging.
This part of AMH1n(D) does not, on its own, specify any profiles.
1.3 Scenario
The model used is one of two end systems running an end-to-end association using either or both of
RTSE and ROSE, and the ACSE, Presentation and Session services and protocols (see figure 1).
Message Message
Handling Handling
ASEs ASEs
ROSE and/or RTSE ROSE and/or RTSE

ACSE ACSE
Presentation Presentation
Session Session
Transport service provider
Figure 1 – Model of the supportive layers
The OSI upper layer services and protocols to support the Message Handling Systems functions covered
by the AMH1n(D) set of profiles are specified in the set of standards identified in table 1.
(Part 2 of Annex C)
Table 1 – AMH1n(D) profile model
Application Layer MHS ISO /IEC 10021-6
ROSE ISO/IEC 9072-2
RTSE ISO/IEC 9066-2
ACSE see ISO/IEC ISP 11188-1
Presentation Layer see ISO/IEC ISP 11188-1
Session Layer see ISO/IEC ISP 11188-1
2 Normative references
The following documents contain provisions that, through reference in this text, constitute provisions of
Amendments and corrigenda to the base standards referenced are listed in annex D of ISO/IEC ISP
11188-1.
be considered to refer also to the corresponding clauses of the equivalent CCITT Recommendations, as
noted below, unless otherwise stated.
ISO/IEC ISP 10611-2: 1994, Information technology – International Standardized Profiles – Messaging
Handling Systems – Common Messaging – Part 2: Specification of ROSE, RTSE, ACSE, Presentation
and Session Protocols for use by MMHS.
Netherlands.)
3 Definitions
To specify the support level of arguments, results and other protocol features for this part of AMH1n(D),
the following terminology is defined.
The specification of levels of support uses the classification defined in ISO/IEC ISP 10611-2.
(Part 2 of Annex C)
4 Abbreviations
The following are additional abbreviations to those defined in ISO/IEC ISP 10611-2.
AARE A-associate-response
AARQ A-associate-request
ACP Allied Communications Publications
Support level for protocol features (see clause 4.2 of ISO/IEC ISP 11188-1):
m mandatory support
5 Conformance
This part of AMH1n(D) states requirements upon implementations to achieve interworking. A claim of
conformance to this part of AMH1n(D) is a claim that all requirements in the relevant base standards are
satisfied, that all the requirements in ISO/IEC ISP 11188-1 are satisfied, and that all requirements in the
following clauses and in the appendices of this part of AMH1n(D) are satisfied. Appendices A, B and C
state the relationship between these requirements and those of the base standards.
The subsequent parts of AMH1n(D) specify the requirements for support of particular MHS application
contexts. The requirements for conformance to this part of AMH1n(D) are, as appropriate to the MHS
application context(s) for which support is claimed, in accordance with ISO/IEC 10021-6.
For each implementation claiming conformance to this part of AMH1n(D), an appropriate set of ISPICS
shall be made available stating support or non-support of each option identified in this part of AMH1n(D).
The ISPICS Proforma in ISO/IEC 10611-2 shall be used to generate the ISPICS.
5.2 Relationship with base standards
5.2.1 ROSE conformance
5.2.2 RTSE conformance
Implementations claiming support of any MMHS application context which includes the Reliable Transfer
Service Element (RTSE) shall implement normal mode. RTSE is only required for reliable application
contexts (i.e., mts-reliable-access, mts-forced-reliable-access, and ms-reliable-access). Implementation
(Part 2 of Annex C)
of X.410-1984 mode is optional. All mandatory support (m) features (as specified in clause 7) shall also
be implemented unless those features are part of an unimplemented optional feature. They shall state
which optional support (o) features are implemented.
5.2.3 ACSE conformance
To conform to the Association Control Service Element (ACSE) protocol used in this part of AMH1n(D),
implementations shall implement Normal mode. Implementation of X.410-1984 mode is optional. All
mandatory support (m) features (as specified in clause 8) shall also be implemented unless those
features are part of an unimplemented optional feature. They shall state which optional support (o)
features are implemented.
5.2.4 Presentation layer conformance
To conform to the Presentation protocol used in this part of AMH1n(D), implementations shall implement
normal mode. Implementation of X.410-1984 mode is optional. All mandatory support (m) features (as
specified in clause 9) shall also be implemented unless those features are part of an unimplemented
optional feature. They shall state which optional support (o) features are implemented.
5.2.5 Transfer syntax conformance
5.2.6 Session layer conformance
6 Remote Operations Service Element (ROSE)
7 Reliable Transfer Service Element (RTSE)
7.1 Dialogue-mode
Two-way alternate dialogue-mode shall be supported for any P1 application context.
7.2 Checkpointing
(Part 2 of Annex C)
7.3 Mode
Normal mode must be supported because the P1 mts-transfer application context is mandated in
AMH1n(D) Part 3.
7.4 Elements of procedure
It is recommended that the RTSE association recovery procedure (clause 7.8.3 of ISO/IEC 9066-2)
should not be used in a secure messaging environment, since the authentication of the RTSE
association may be compromised (this is currently the subject of an RTSE defect report). It is
permissible, however, to use the RTSE activity resumption procedure (clause 7.8.1 of ISO/IEC 9066-2)
on an existing, authenticated, RTSE association.
8 Association Control Service Element (ACSE)
9 Presentation layer
10 Session layer
10.1 Session version
Session version 2 must be supported because the P1 mts-transfer application context is mandated in
AMH1n(D) part 3.
(Part 2 of Annex C)
Appendix A
(normative)
SPICS Requirements List
Specific Upper Layer Requirements for ACSE,
Presentation and Session
A.1 General
this appendix, this appendix is to take precedence.
The tables of this appendix specify the level of support for the Session, Presentation and ACSE
protocols, as required by the Standardized Profiles AMH1n(D). Where features of these protocols are
not specified in the tables of this appendix then the requirements for conformance to this part of
AMH1n(D) are as specified in the corresponding annex of ISO/IEC ISP 10611-2. Any elements which
are marked as * (i.e. referencing SP's choice) in the corresponding annex of ISO/IEC ISP 10611 and
which are not resolved in this appendix are to be considered as o for the purposes of conformance to this
part of AMH1n(D).
A.2 Classification of requirements
The "Profile" column reflects the level of support required by this SP. The specification of levels of
support uses the classification defined in ISO/IEC ISP 10611-2.
A.3 Association Control Service Element
A.3.1 Supported roles
A.3.1.1 Association establishment
A.3.2 Protocol mechanisms
Ref Protocol Mechanism Profile
1 Normal mode m
4 Supports operation of Session v2 m
A.3.3 Supported APDU parameters

A.4 Presentation protocol
A.5 Session protocol
A.5.1 Protocol versions implemented
Ref Version Profile
2 Version 2 m
A.5.2 Functional units
A.5.3 Protocol mechanisms

Appendix B
(normative)
SPICS Requirements List for RTSE
B.1 General
The tables of this appendix specify the level of support for the RTSE protocol, as required by the
Defense Standardized Profiles AMH1n(D). This appendix is completely based on ISO/IEC ISP 10611. It
uses only a selection of the tables from that Profile which are necessary for the specification of SP
requirements. Where features of this protocol are not specified in the tables of this appendix then the
requirements for conformance to this part of AMH1n(D) are as specified in ISO/IEC ISP 10611-2.
In each table, the "Base" column reflects the level of support required for conformance to the base
standard and the "Profile" column reflects the level of support required by this SP. The specification of
levels of support uses the classification defined in ISO/IEC ISP 10611-2.
B.2 Initiator/responder capability
B.3 Major capabilities
B.3.1 Protocol Mechanisms
1 Normal mode m
B.3.2 Dialogue mode
4 Two-way alternate dialogue-mode m
B.4 Additional Information
(Appendix B to Part 2 of Annex C)

Appendix C
(normative)
SPICS Requirements List for ROSE
C.1 General
C.2 Application entity requirements
(Appendix C to Part 2 of Annex C)

(Appendix C to Part 2 of Annex C)


Part 3: AMH11(D) – MMHS Requirements for Message Transfer (P1)
(Part 3 of Annex C)
Introduction
This part of AMH1n(D) covers MMHS requirements for Message Transfer (P1). It specifies any
additional P1 support to that specified in ISO/IEC ISP 10611 and defines conformance requirements for
an MTA which supports transfer with respect to support of P1 and associated functionality (requiring
conformance to AMH11 and by reference to the common MMHS specifications in part 1).
This part of AMH1n(D) contains one normative appendix.
Appendix A (normative) SPICS Requirements List for AMH1n(D) Part 3 (AMH11(D))
(Part 3 of Annex C)

Messaging
Part 3: AMH11(D) – MMHS Requirements for Message
Transfer (P1)
1 Scope
1.1 General
This part of AMH1n(D) covers message transfer between Message Transfer Agents (MTAs) in the MMHS
using the P1 Message Transfer Protocol (see also figure 1). These specifications form part of the
Common Unrestricted Messaging application functions, as defined in the parts of AMH1n(D), and are
based on the Common Messaging content type-independent specifications in ISO/IEC ISP 10611-3.
This part of AMH1n(D) is the third part of a multipart SP for AMH1n(D) Military Message Handling
Systems.
This part of AMH1n(D) specifies the following profile:
AMH11(D) – MMHS Requirements for Message Transfer (P1)
Handling Systems – Common Messaging” (see also ISO/IEC TR 10000-1, 8.2 for the definition of
multipart ISPs).
It may be combined with any approved T-Profiles (see ISO/IEC TR 10000) OSI connection-mode
Transport service.
1.3 Scenario
The model used is one of two or more MTAs intercommunicating within a Message Transfer System
(MTS) using the P1 protocol, as shown in figure 1.
P1 P1
MTA MTA MTA
Error! Switch argument not
specified.
Figure 1 – AMH11(D) scenario
The AMH11(D) profile covers all aspects of the MTA Abstract Service, as defined in clause 12 of
ISO/IEC 10021-4 when realized using the P1 protocol in the MMHS.
(Part 3 of Annex C)
2 References
Technical corrigenda to the base standards referenced are listed in appendix B of ISO/IEC ISP 10611-3.
ACP 123: Common Messaging Strategy and Procedures, November 1994
ISO/IEC ISP 10611-3: 1994, Information technology – International Standardized Profiles – Message
Handling Systems – Common Messaging – Part 3: AMH11 – Message Transfer (P1).


Exchange 1994.


Netherlands.)
3 Definitions
Terms used in this part of AMH1n(D) are as defined in the referenced base standards, in addition, the
terms defined in ISO/IEC 10611-3 apply.
(Part 3 of Annex C)

MM Military Message
MTSE Message Transfer Service Element
P1 MTS Transfer Protocol
P772 MMS Protocol
PICS Protocol Implementation Conformance Statement
RTSE Remote Transfer Service Element
SC Subcommittee
SEC Security
SMA Single Message Address
WG Working Group
Support level for protocol elements and features (see 3.2):
m mandatory full support

m- mandatory minimal support
o optional
r required, dynamically mandatory
x prohibited
5 Conformance
satisfied, and that all requirements in the following clauses and in appendix A of this part of AMH1n(D)
are satisfied. Appendix A states the relationship between these requirements and those of the base
standards.
(Part 3 of Annex C)
For each implementation claiming conformance to profile AMH11(D), an ISPICS shall be made available
stating support or non-support of each option identified in this part of AMH1n(D). The ISPICS Proforma
in ISO/IEC 10611-5 shall be used to generate the ISPICS.
The scope of conformance to profile AMH11(D) is restricted to MTAs. A claim of conformance to

AMH11(D) shall support profile AMH111. Support of the profile AMH112 is optional. Profiles AMH111
and AMH112, as obtained in ISO/IEC ISP 10611-3, are jointly referenced as AMH11 in this part of
AMH1n(D) except where distinction is necessary.
5.2 MHS conformance
This part of AMH1n(D) specifies implementation options or selections such that conformant
implementations will satisfy the conformance requirements of ISO/IEC 10021 and/or the CCITT X.400
Recommendations.
Implementations conforming to profile AMH11(D) shall as a minimum conform to the basic requirements
of profile AMH11, as specified in ISP/IEC ISP 10611-3.
Implementations conforming to profile AMH11(D) shall additionally implement all the mandatory support
(m) features identified as basic requirements in appendix A. They shall also support corresponding MHS
Elements of Service and associated procedures as specified in AMH1n(D) Part 1, as appropriate to the
scope of this profile.
Implementations conforming to profile AMH11(D) shall state whether or not they support any of the
optional functional groups as specified in AMH1n(D) Part 1 which are applicable to the scope of this
profile. For each functional group for which support is claimed, an implementation shall additionally
implement all the mandatory support features (m) identified for that functional group in appendix A.
They shall also support corresponding MHS Elements of Service and associated procedures as specified
in AMH1n(D) Part 1, as appropriate to the scope of this profile.
Implementations conforming to profile AMH11(D) shall state the P1 application context(s) for which
conformance is claimed.
5.3 Underlying layers conformance
Implementations conforming to profile AMH11(D) shall also meet the requirements for support of
underlying layers as specified in subclause 5.3 of ISO/IEC ISP 10611-3.
(Part 3 of Annex C)
Appendix A
(normative)
SPICS REQUIREMENTS LIST FOR
AMH1n(D) Part 3 (AMH11(D))
This appendix specifies the support constraints and characteristics of AMH1n(D) Part 3 on what shall or
may appear in the implementation columns of a ISPICS. Such requirements are additional to those
specified in annex A of ISO/IEC 10611-3 (reference numbers correspond to items in that annex).
Clause A.1 specifies the basic requirements for conformance to profile AMH11(D). Clause A.2 specifies
additional requirements to those specified in A.1 for each of the optional functional groups if
conformance to such a functional group is claimed.
In each table, the "Profile" column reflects the level of support required for conformance to this SP (using
the classification and notation defined in clause 3.2). The supplier of an implementation for which
conformance to profile AMH11(D) is claimed should complete the Support column of the tables in annex
A of ISO/IEC ISP 10611-3 in accordance with the requirements contained therein together with any
additional requirements in this appendix.
A.1 Basic requirements
The following are additional requirements beyond those stated in ISO/IEC 10611-3.
A.1.1 Initiator/responder capability
A.1.2 Supported application contexts
Conformance to AMH111 is mandatory.
A.1.3 Supported operations
A.1.3.2 Message Transfer Service Element (MTSE)
Ref Operation Profile

1
3 ProbeTransfer x
Note:
1 Reception of a Probe at the MTA will be logged as a security violation
and no delivery or non-delivery report will be returned.
(Part 4 of Annex C)
A.1.4 Operation arguments\results
A.1.4.2 MessageTransfer
Ref Element Profile
1.1.4 content-type m
1.1.6 priority mr
1.1.11.4 latest-delivery-time m
1.2.5.1 originator-requested-alternate-recipient m
1.2.5.13 redirection-history m
A.1.5 Common data types
Ref Element Profile
6.1.2.4.3 other-actions m
6.1.2.4.3.1 redirected m
A.1.6 Extension data types
Ref Element Profile
5.3.4.3 other-actions m
5.3.4.3.1 redirected m
A.1.7 O/R names
Ref Element Profile
1 mnemonic O/R Address m
2 numeric O/R Address m
6 directory-name m
A.1.7.1 Mnemonic O/R address
Ref Element Profile
2 built-in-domain-defined-attributes m
1
2.1 acp-plad m-
2
2.2 acp-ri m-
Notes:
1 This element can be any acp-address including, but not limited to
PLADs, SMAs, AIGs, and CADs.
2 This element can be any RI, including collective RIs.
(Part 4 of Annex C)
A.1.7.2 Numeric O/R address
Ref Element Profile
2 built-in-domain-defined-attributes m
1
2.1 acp-plad m-
2
2.2 acp-ri m-
Notes:
1 This element can be any acp-address including, but not limited to
PLADs, SMAs, AIGs, and CADs.
A.1.7.3 Terminal O/R address
A.2 Functional groups
A.2.1 Mandatory functional groups
The following functional groups that are optional in ISO/IEC 10611-3, are mandatory in this profile as
specified in this part of AMH1n(D):
Redirection (RED)
Latest Delivery (LD)
Use of Directory (DIR)
There are no additional requirements to those specified for support of these functional groups.
A.2.2 Optional functional groups
The following requirements are additional to those specified in A.1 if support of the optional functional
group is claimed.
The Security (SEC), Physical Delivery (PD), Conversion (CV), and Distribution List (DL) FGs may
optionally be implemented in this profile; however, there are no additional requirements for support of
these FGs other than the requirements stated in ISO/IEC 10611-3.
A.2.3 Prohibited functional groups
The following functional groups that are optional in ISO/IEC 10611-3, are prohibited in this profile as
specified in this part of AMH1n(D).
The use of the Return of Contents functional group is prohibited in this profile as specified in AMH1n(D)
Part 1.
(Part 4 of Annex C)
A.3 Additional Information
(Part 4 of Annex C)

Part 4: AMH12(D) – MMHS Requirements for MTS Access (P3)
(Part 4 of Annex C)
Introduction
This part of AMH1n(D) covers MMHS requirements for MTS Access (P3). It specifies any additional P3
support to that specified in ISO/IEC ISP 10611 and defines conformance requirements for an MTA which
supports remote access for MMHS use, and for a remote MTS-user in the MMHS (i.e., MM-UA or MM-
MS), with respect to support of P3 and associated functionality (requiring conformance to AMH12 and by
reference to the common MMHS specifications in part 1).
(Part 4 of Annex C)

Messaging
Part 4 : AMH12(D) – MMHS Requirements for MTS Access
Protocol (P3)
1 Scope
1.1 General
This part of AMH1n(D) covers access to a Message Transfer System (MTS) in the MMHSusing the P3
MTS Access Protocol (see also figure 1). These specifications form part of the Common Unrestricted
Messaging application functions as defined in the parts of AMH1n(D), and are based on the Common
Messaging content type-independent specifications in ISO/IEC ISP 10611-4.
This part of AMH1n(D) is the fourth part of a multipart SP for AMH1n(D) Military Message Handling
Systems.
AMH12(D) – MMHS Requirements for MTS Access (P3)
multipart ISPs).
It may be combined with any approved T-Profiles (see ISO/IEC TR 10000) specifying OSI connection-
mode Transport service.
1.3 Scenario
The model used is one of access to an MTS by an MMHS MTS-user - specifically, the interconnection
between a message transfer agent (MTA) and an MTS-user using the P3 protocol, as shown in figure
1.Error! Switch argument not specified.
P3 P3 out of
MM-UA MTA MM-MS scope MM-UA
The AMH12(D) profile covers all aspects of the MTS Abstract Service, as defined in clause 8 of ISO/IEC
10021-4 when realized using the P3 protocol in the MMHS.
(Part 4 of Annex C)
2 References
Handling Systems – Common Messaging – Part 4: AMH12 – MTS Access (P3).


Exchange 1994.


Netherlands.)
3 Definitions
Terms used in this part of AMH1n(D) are defined in the referenced base standards, in addition, the terms
defined in ISO/IEC 10611-4 apply.
(Part 4 of Annex C)

MM Military Message
MSSE Message Submission Service Element
P3 MTS Access Protocol
P772 MMS Protocol
RI Rounting Indicator
SC Subcommittee
WG Working Group

c conditional
x excluded
5 Conformance
are satisfied. Appendix A states the relationship between these requirements and those of the base
standards.
(Part 4 of Annex C)
For each implementation claiming conformance to profile AMH12(D), a ISPICS shall be made available
The scope of conformance to profile AMH12(D) covers both MTAs and MTS-users. A claim of
conformance to profile AMH12(D) shall state whether an implementation claims conformance as an
MTA, as a MM-UA, or as an MM-MS which is not co-located with an MTA.
A claim of conformance to profile AMH12(D) shall confirm that the implementation supports profile
AMH12 as specified in ISO/IEC 10611-4.
5.2 MHS conformance
implementations will satisfy the conformance requirements of ISO/IEC 10021 and the CCITT X.400
Recommendations.
Implementations conforming to profile AMH12(D) shall as a minimum conform to the basic requirements
of profile AMH12, as specified in ISO/IEC 10611-4, as appropriate to the type of implementation (i.e.
MTA or MTS-user) for which conformance is claimed.
Implementations conforming to profile AMH12(D) shall additionally implement all the mandatory support
(m) features identified as basic requirements in appendix A. They shall also support corresponding MHS
scope of this profile.
profile. For each functional group for which support is claimed, an implementation shall additionally
implement all the mandatory support (m) features identified for that functional group in appendix A.
They shall also support corresponding MHS Elements of Service and associated procedures as specified
in AMH1n(D) Part 1, as appropriate to the scope of this profile.
Implementations conforming to profile AMH12(D) shall state the P3 application context(s) for which
(Part 4 of Annex C)
Appendix A
(normative)
for AMH1n(D) Part 4 (AMH12(D))

specified in annex A of ISO/IEC 10611-4 (reference numbers correspond to items in that annex).
conformance to profile AMH12(D) is claimed should complete the ISPICS referred to by annex A of
ISO/IEC 10611-4 in accordance with the requirements contained therein together with any additional
requirements in this appendix for the type of implementation (i.e. MTA or MTS-user) in question.
(Note: Some parts of appendix A require completion of the IO-ICS in ACP 123)
A.1.2.2 Message Submission Service Element (MSSE)
Ref Operation MTS-user MTA
Profile Profile
1
2 ProbeSubmission x x
2
3 CancelDeferredDelivery c
Notes:
1 Reception of Probe at the MTA will be logged as a security violation and no delivery or
non-delivery report will be returned.
2 Mandatory if Deferred Delivery is supported, else optional.

A.1.3 Operation arguments/results
A.1.4 MessageSubmissionEnvelope
Ref Element MTS-user MTA
Profile Profile
5 priority mr mr
8.4 latest-delivery-time m
9.4.1 originator-requested-alternate-recipient m m
A.1.5 ProbeSubmissionEnvelope
Probes are dynamically prohibited in this profile as specified in this part of AMH1n(D).
A.1.6 MessageDeliveryEnvelope
Profile Profile
3.4 priority mr
3.12.19 dl-expansion-history-indication m
A.1.7 ReportDeliveryEnvelope
Profile Profile
4.2 extended m
5.3 alternate-recipient-allowed m
1
5.4 content-return-request m m
Note:
1 The content-return-request shall be present and set to not request return of content.

A.1.10 O/R names
Profile Profile
1 mnemonic O/R Address m
2 numeric O/R Address m m
6 directory-name m m
Profile Profile
2 built-in-domain-defined-attributes m m
1
2.1 acp-plad m- m-
2
2.2 acp-ri m- m-
Notes:
1 This element can be any acp-address including, but not limited to PLADs, SMAs,
AIGs, and CADs.
Profile Profile
1
2.1 acp-plad m- m-
2
2.2 acp-ri m- m-
Notes:
AIGs, and CADs.

Redirection (RED)
User of Directory (DIR)
The following requirements are additional to those specified in A.1 if support of the functional group is
claimed.
The Security (SEC), Physical Delivery (PD), Conversion (CV), and Distribution List (DL) FGs may
optionally be implemented in this profile; however, there are no additional for support of these FGs other
than the requirements stated in ISO/IEC 10611-4.
specified in this part of AMH1n(D). The use of the Return of Contents functional group is prohibited in
this profile as specified in AMH1n(D) Part 1.
A.3 Additional information


Part 5: AMH13(D) – MMHS Requirements for MS Access (P7)
(Part 5 of Annex C)
Introduction
This part of AMH1n(D) covers access to an MM-MS using the P7 MS Access Protocol in the MMHS. It
specifies any additional P7 support to that specified in ISO/IEC ISP 10611-5 and defines conformance
requirements for an MS which supports remote access for MMHS use, and for a remote MS-user in the
MMHS(i.e., MM-UA), with respect to support of P7 and associated functionality (requiring conformance
to AMH13 and by reference to the common MMHS specifications in part 1).
(Part 5 of Annex C)

Messaging
Part 5: AMH13(D) – MMHS Requirements for MS Access
Protocol (P7)
1 Scope
1.1 General
This part of AMH1n(D) covers access to a Message Store (MS) in the MMHS using the P7 MS Access
Protocol (see also figure 1). These specifications form part of the Common Unrestricted Messaging
application functions, as described in the parts of AMH1n(D), and are based on the Common Messaging
content type-independent specifications in ISO/IEC ISP 10611-5.
This part of AMH1n(D) is the fifth part of a multipart SP for AMH1n(D) Military Message Handling
Systems.
AMH13(D) – MMHS Requirements for MS Access (P7)
multipart ISPs).
It may be combined with any approved T-Profiles (see ISO/IEC TR 10000) the OSI connection-mode
Transport service.
1.3 Scenario
The model used is one of access to an Military Messaging Message Store (MM-MS) by an MM MS-user
– specifically, the interconnection between an MM-MS and an MS-user (i.e., an MM-UA) using the P7
protocol, as shown in figure 1.
P7
MM-UA MM-MS
The AMH13(D) profile covers all aspects of the MS Abstract Service, as defined in ISO/IEC 10021-5,
when realized using the P7 protocol in the MMHS.
(Part 5 of Annex C)
2 References
Handling Systems – Common Messaging – Part 5: AMH13 – MS Access (P7).


Exchange 1994.


Netherlands.)
3 Definitions
Terms used in this part of AMH1n(D) are defined in the referenced base standards, in addition, the terms
defined in ISO/IEC 10611-5 apply.
(Part 5 of Annex C)

MM Military Message
MRSE Message Retrieval Service Element
MSSE Message Submission Service Element
P7 MS Access Protocol
P772 MMS Protocol
RoC Return of Content
SC Subcommittee
SP Standardized Profile
SPICS Standardized Profile Implementation Conformance Statement
WG Working Group

o optional support
i out of scope
x excluded
5 Conformance
are satisfied. Annex A states the relationship between these requirements and those of the base
standards.
(Part 5 of Annex C)
For each implementation claiming conformance to profile AMH13(D), a ISPICS shall be made available
The scope of conformance to AMH13(D) covers both MM-MSs and MS-users (i.e. MM-UAs). A claim of
conformance to profile AMH13(D) shall confirm that the implementation supports profile AMH13 as
specified in ISO/IEC ISP 10611-5 and shall state whether the implementation supports MM-MS or MS-
user functionality.
5.2 MHS conformance
implementations will satisfy the conformance requirements of ISO/IEC 10021 and the CCITT X.400
Recommendations.
Implementations conforming to profile AMH13(D) shall implement the mandatory support (m) features
identified as basic requirements in appendix A. They shall also support corresponding MHS Elements of
Service and associated procedures as specified in AMH1n(D) Part 1, as appropriate to the scope of this
profile and to the role (i.e., MM-MS or MS-user) for which conformance is claimed.
profile and to the role (i.e., MM-MS or MS-user) for which conformance is claimed. For each functional
group for which support is claimed, an implementation shall implement all the mandatory support (m)
features identified for that functional group in appendix A. They shall also support corresponding MHS
scope of this profile and to the role (i.e., MM-MS or MS-user) for this conformance is claimed.
Implementations conforming to profile AMH13(D) shall state the P7 application context(s) for this
(Part 5 of Annex C)
Appendix A
(normative)
for AMH1n(D) Part 5 (AMH13(D))

specified in annex A of ISO/IEC ISP 10611-5 (reference numbers correspond to items in that annex).
conformance to profile AMH13(D) is claimed should complete the ISPICS referred to by annex A of
ISO/IEC ISP 10611-5 in accordance with the requirements contained therein together with any additional
requirements in this appendix for the type of implementation (i.e. MM-MS or MS-user) in question.
(Note: Some parts of appendix A require completion of IO-ICS in ACP 123.)
A.1.2.2 Message Submission Service Element (MSSE)
Ref Operation UA MS
Profile Profile
2 ProbeSubmission x x
1
3 CancelDeferredDelivery c
Notes:
1 Mandatory if Deferred Delivery is supported, else optional.

A.1.2.3 Message Retrieval Service Element (MRSE)
Ref Operation UA MS
Profile Profile
1 Summarize m
2 List m
A.1.3 Operation arguments/results
A.1.4 MessageSubmissionEnvelope
Ref Operation UA MS
Profile Profile
5 priority mr mr
8.4 latest-delivery-time m
9.4.1 originator-requested-alternate-recipient m m
A.1.5 ProbeSubmissionEnvelope
Probes are out of scope of this profile as specified in this part of AMH1n(D).
A.1.6 AutoForwardRegistrationParameter
A.1.7 AutoAlertRegistrationParameter

Ref Operation UA MS
Profile Profile
11.2 extended m
1
12.3 alternate-recipient-allowed m
2
12.4 content-return-request m m
Notes:
1 The dynamic behavior of the alternate-recipient-allowed element is to set to allow
alternate recipients unless specifically set to disallowed by the originator. So as a
default, this argument shall be set to alternate-recipient-allowed (Note: this effectively
changes the base standard default to allow alternative recipients).
2 The content-return request shall be present and set to not request return of content.
A.1.10 O/R names
Ref O/R Name Form UA MS
Profile Profile
2 Numeric O/R Address m
6 Directory Name m
Profile Profile
1
2.1 acp-plad m- m-
2
2.2 acp-ri m- m-
Notes:
AIGs, and CADs.

Profile Profile
1
2.1 acp-plad m- m-
2
2.2 acp-ri m- m-
Notes:
AIGs, and CADs.
A.1.11 General Attributes

Use of Directory (DIR)
The following requirements are additional to those specified in A.1 if support of the functional group is
claimed.
The Security (SEC) and Physical Delivery (PD) FGs may optionally be implemented in this profile;
however, there are no additional requirements for support of these FGs other than the requirements
stated in ISO/IEC 10611-5.
specified in this part of AMH1n(D). The use of the Return of Contents functional group is prohibited in
this profile as specified in AMH1n(D) Part 1.

A.3 Additional information


UNCLASSIFIED ANNEX D to ACP 123
ANNEX D
TITLE: Information technology - Standardized Profiles -

Military Message Handling Systems - Content Types
FMH11(D) - MM Content (P772)
This document is a Standardized Profile (SP) for Military Message Handling Systems
(MMHS) covering Military requirements. It is outside the scope of the current Taxonomy
Framework for International Standardized Profiles (ISP). This SP is a content specific profile
for the Military Message (MM) content type referred to as P772 as defined in the Allied
Communication Publication (ACP) 123. This SP only specifies requirements for content
specific functionality for any implementation that supports the MM content type.
UNCLASSIFIED D-1 ORIGINAL

Introduction
Information Technology (IT) standardization activities - covering base standards, profiles, and
FMH11(D) covers content specific functionality for any implementation that supports the MM content
type. It specifies support of the MM content 'protocol' in terms of basic requirements and optional
functional groups and defines conformance requirements for implementations with respect to support of
the MM content and associated functionality.
FMH11(D) contains two normative appendices:
Appendix A MM Elements of Service

Appendix B SPICS Requirements List for FMH11(D)

Information technology – Standardized Profiles – Military

Message Handling Systems – Content Types
FMH11(D) – MM Content (P772)
1 Scope
1.1 General
FMH11(D) covers the representation of the MM content type (P772) by conforming implementations (see
also figure 1). These specifications form part of the MMHS application functions.
FMH12(D) specifies the profile which states requirements for the MM content-type.
1.3 Scenario
The model assumes the exchange of military messages (content type P772) by two cooperating
implementations. The P772 information objects originated and received by the implementations may be
transferred via either:
1. a direct connection between the implementations (i.e., an A-profile);

2. direct connections to a relaying system (which need not comply with this profile);
3. by other bilaterally agreed means.
The specific transfer mechanism used must be mutually agreed but is outside the scope of this profile.
This relationship is illustrated in figure 1.
MM MM
Implementation Implementation
R e lay System (optional)
Error! Switch argument not specified.
Figure 1 – FMH11(D) scenario
The MHS services and functions covered by the FMH11(D) profile are specified in ACP 123. There are
no OSI upper layer services and protocols within the scope of the FMH11(D) profile.

2 References
FMH11(D). At the time of publication, the editions indicated were valid. All documents are subject to
revision, and parties to agreements based on FMH11(D) are warned against automatically applying any
more recent editions of the documents listed below, since the nature of references made by SPs to such
documents is that they may be specific to a particular edition. Members of IEC and ISO maintain
registers of currently valid International Standards and ISPs, and CCITT maintains published editions of
its current Recommendations.
Technical corrigenda to the base standards referenced are listed in appendix B of the IO-ICS.
NOTE – References in the body of FMH11(D) to specific clauses of ISO/IEC documents shall be
considered to refer also to the corresponding clauses of the equivalent CCITT Recommendations (as
ISO/IEC TR 10000-1: 1992, Information technology – Framework and taxonomy of International

Standardized Profiles – Part 1: Framework.
ISO/IEC TR 10000-2: 1992, Information technology – Framework and taxonomy of International

Standardized Profiles – Part 2: Taxonomy.

(MOTIS) – Part 1: System and Service Overview, Amendment 2: Message Store Extensions 1994.

Exchange 1994.

Netherlands.)
3 Definitions
For the purposes of FMH11(D), the following definitions apply. Terms used in FMH11(D) are defined in
the referenced base standards. In addition, the following terms are defined.
3.1 General
MM base standard : the base standard referred to in this F-profile is ACP 123.
Basic requirement : an Element of Service, protocol element, procedural element or other identifiable
feature specified in the base standards which is required to be supported by all MMHS implementations
conforming to this SP.

Functional group : a specification of one or more related Elements of Service, protocol elements,
procedural elements or other identifiable features specified in the base standards which together support
a significant optional area of MHS functionality.
NOTE – A functional group can cover any combination of MHS features specified in the base standards
for which the effect of implementation can be determined at an external interface – i.e., via a
communications protocol (other forms of exposed interface are outside the scope of this version of
FMH11(D)).
3.2 Support classification
To specify the support level of arguments, results and other protocol features for FMH11(D), the
following terminology is defined.
The classification of information objects and items (elements) is relative to that of the containing
information element, if any. Where the constituent elements of a non-primitive element are not
individually specified, then each shall be considered to have the classification of that element. Where
the range of values to be supported for an element is not specified, then all values defined in the MM
base standard shall be supported.
3.2.1 Static capability
The following classifications are used in FMH11(D) to specify static conformance requirements – i.e.,
capability.
mandatory support (m) : the element or feature shall be supported. An implementation shall be able to
generate the element, and/or receive the element and perform all associated procedures (i.e., implying
the ability to handle both the syntax and semantics of the element) as relevant, as specified in the MM
base standard. Where support for origination (generation) and reception are not distinguished, then both
capabilities shall be assumed.
NOTE – Where required by the base standards, mandatory support also implies that the implementation
shall be able to pass the element on the origination port/reception port to/from the corresponding element
on the submission port/delivery port/retrieval port.
optional support (o) : an implementation is not required to support the element. If support is claimed,
the element shall be treated as if it were specified as mandatory support. If support for origination is not
implementation may ignore the element on delivery, but will not treat it as an error.
conditional support (c) : the element shall be supported under the conditions specified in FMH11(D). If
these conditions are met, the element shall be treated as if it were specified as mandatory support. If
these conditions are not met, the element shall be treated as if it were specified as optional support
(unless otherwise stated).
out of scope (i) : the element is outside the scope of FMH11(D) – i.e., it will not be the subject of a SP
conformance test.
3.2.2 Dynamic behavior
The above classifications are used in FMH11(D) to specify static conformance requirements (i.e.,
capability); dynamic conformance requirements (i.e., behavior) are as specified in the MM base

standards. However, in a few cases it has been necessary to specify additional dynamic conformance
requirements in this profile. These are specified using a second classification code for an element as
follows.
required (r) : the element shall always be present. An implementation shall ensure that the element is
always generated or otherwise used, as appropriate. Absence of the element on reception shall result in
termination or rejection of the communication with an appropriate error indication as specified in the MM
base standards.
prohibited (x) : the element shall not be originated by an implementation claiming conformance to this
profile, if the element is received it may be treated as a protocol violation unless otherwise stated.

AMH Application Message Handling
CCITT International Telegraph and Telephone Consultative Commitee
FG Functional group
ITU International Telecommunications Union
ITU-T ITU Telecommunications Standardization Sector
MM Military Message
MN Military Notification
MOTIS Message-Oriented Text Interchange Systems
ODA Open Document Architecture
SEC Security
SP Standardized Profile
SPICS Standardized Profile Implementation Conformance Statement
Support level for protocol elements and features (see clause 3.2):

o optional support
c conditional support
i out of scope
x prohibited, dynamically excluded

5 Conformance
The scope of conformance to profile FMH11(D) covers content specific functionality for any
implementation that supports the MM content type. Conformance to profile FMH11(D) does not imply
the provision of a standard OSI communications protocol for access to the MTS.
FMH11(D) states requirements upon implementations to achieve interworking. A claim of conformance

to FMH11(D) is a claim that all requirements in the relevant base standards are satisfied, and that all
requirements in the following clauses and in appendices A and B of FMH11(D) are satisfied. Appendix B
states the relationship between these requirements and those of the base standards.
For each implementation claiming conformance to profile FMH11(D), a IO-ICS shall be made available
stating support or non-support of each option identified FMH11(D). The IO-ICS Proforma in annex B of
ACP 123 shall be used to generate the IO-ICS.
5.2 MHS conformance
FMH11(D) specifies implementation options or selections such that conformant implementations will
satisfy the conformance requirements for ACP 123 military messages.
Implementations conforming to profile FMH11(D) shall implement all the mandatory support (m) features
identified as profile requirements in appendices A and B and shall state which optional support (o)
features are implemented.
Implementations conforming to profile FMH11(D) shall state whether or not they support any of the
optional functional groups as specified in clause 7. For each functional group for which support is
claimed, an implementation shall support MM Elements of Service and associated procedures as
specified in appendix A of this profile.
6 Basic Requirements
Appendix A specifies the basic requirements for support of MM EoS for conformance to FHM11(D). This
clause qualifies the basic requirements for specific MM features.
6.1 Message Length
If an implementation imposes any constraint on the size of the message content, then such constraints
shall be stated in the IO-ICS.
6.2 Number of recipients
If an implementation imposes any limit on the number of recipients that can be specified in an MM
heading, then such a limit shall be stated in the IO-ICS.

7 Functional Groups
Appendix A also specifies additional requirements for support of MM EoS if support of an optional
functional group (FG) is claimed, as appropriate to the MM content type (P772). The following subclause
summarizes the functionality supported by the optional FG and identifies particular requirement or
implementation considerations which are outside the scope of formal conformance to FMH11(D).
7.1 ACP 127 Interworking (ACP127)
The ACP 127 Interworking FG covers interworking between implementations conforming to MMHS and
the older messaging system following ACP 127 guidelines. Interworking takes place by means of a
gateway that performs conversion between the two formats. Such a gateway may originate ACP 123
transitional EoS as part of the conversion process. If conformance to this FG is claimed, the
implementation shall support reception of those transitional EoS and related P772 protocol elements as
specified in appendices A and B. This FG may improve interworking with ACP 127 systems during a
transition period.
This FG requires support on reception for these services including user interface display requirements.
Even if support of the ACP127 FG is claimed, these services are not required to be supported on
origination.
It is recommended that support for this FG be a configurable option, so it may be turned off when no
longer required.
8 Naming and Addressing
Support for the mnemonic and numeric address forms and for directory names is mandatory. In
addition, implementations shall support the Domain Defined Attributes (DDA) acp-plad and acp-ri for
both origination and reception as defined in ACP 123 annex A.

Appendix A
(normative)
MM Elements of Service
A.1 MM-specific Elements of Service
The following tables specify the requirements for support of MM-specific Elements of Service by a
conforming implementation.
In the following tables, the "Profile" column reflects the basic requirements for conformance to
FMH11(D) - i.e. the minimum level of support required by all implementations claiming conformance to
this profile (see clause 6). The "Functional Group" column specifies any additional support requirements
if support of an optional functional group is claimed (see clause 7). Each column is then further
subdivided into support for origination ("Orig") and reception ("Rec") as defined in clause 3.2, together
with the abbreviated name of the functional group ("FG") in the case of the second column.
Table A.1 - Elements of Service Belonging to the Basic MM Service (MM EoS)
Orig. Rec. FG Orig. Rec.
Copy Precedence m m
IPM-message Identification m m
Primary Precedence m m
Subject Indication m m
Typed Body m m
Table A.2 MM Optional User Facilities (MM EoS)
ACP127 Message Identifier o o ACP127 o m
ACP127 Notification Request o i ACP127 o i
ACP127 Notification Response i o ACP127 i o
Authorizing Users Indication m m
Auto-forwarded Indication o m
Blind Copy Recipient Indication m m
Body Part Encryption Indication o m
Clear Service o m
Codress Message indicator o o ACP127 o m
Corrections o o ACP127 o m
(Appendix A to Annex D)
Cross-referencing Indication m m
Distribution Code m m
Exempted Addresses m m
Expiry Date Indication m m
Extended Authorization Info m m
Forwarded Message Indication m m
Handling Instructions o o ACP127 o m

3
Importance Indication i i
Incomplete Copy Indication m m
Language Indication m m
Message Instructions m m
Message Type m m
Multi-part Body Indication m m

1
Non-receipt Notification Request Indication m c
Obsoleting Indication m m
Originator Indication m m
Originator Reference m m
Originator PLAD o o ACP127 o m
Other Recipient Indicator m m
Pilot Forwarded o o ACP127 o m
Primary and Copy Recipients Indication m m

2
Receipt Notification Request Indication m m
Reply Request Indication m m
Replying Message Indication m m

3
Sensitivity Indication i i
Use of Address List o m
Notes:
1 If any condition that could result in an NRN is supported, origination for NRN must also be supported. If an implementation
can request a Non-receipt notification, it must be able to display it for the user if received.
2 If a Receipt Notification is received, the implementation must be able to display it for the user.
3 The originator's user interface shall not prompt for this EoS. If the protocol that supports this EoS is present upon reception
then the EoS shall not be displayed to the user.
(Appendix A to Annex D)
UNCLASSIFIED D - 10 ORIGINAL
Appendix B
(normative)
SPICS REQUIREMENTS LIST FOR FMH11(D)

In the event of a discrepancy becoming apparent in the body of FMH11(D) and the tables in this
appendix, this appendix is to take precedence.
This appendix specifies the support constraints and characteristics of FMH11(D) on what shall or may
appear in the implementation columns of a completed IO-ICS.
Clause B.1 specifies the basic requirements for conformance to profile FMH11(D).
the classification and notation defined in clause 3.2).
The "References" column has cross references to other relevant parts of this appendix. When it
specifies another table, that table is an expansion of the line at which the reference occurs. If a line
number is specified, only that line is related to the line at which the reference occurs. A number in
parenthesis () after a table reference refers to that line in the specified table.
B.1 Basic requirements
B.1.1 Supported information objects
Ref Element Profile References
Orig. Rec.
1 Military Message (MM) m m
1.1 heading m m see B.1.2
1.2 body m m see B.1.3

1
2 Military Notification (MN) m m see B.1.4
Notes:
1 If the conditions for which a Non-Receipt Notification would be generated are not supported, the
ability to generate a Non-Receipt Notification is optional.
B.1.2 MM heading fields
Orig. Rec.
1 this-IPM mr m see B.1.5(3)
2 originator m m see B.1.5(2)
3 authorizing-users m m see B.1.5(2)
4 primary-recipients m m see B.1.5(1)
(Appendix B to Annex D)
Orig. Rec.
5 copy-recipients m m see B.1.5(1)
6 blind-copy-recipients m m see B.1.5(1)
7 replied-to-IPM m m see B.1.5(3)
8 obsoleted-IPMs m m see B.1.5(3)
9 related-IPMs m m see B.1.5(3)
10 subject mr m
11 expiry-time m m
12 reply-time m m
13 reply-recipients m m see B.1.5(2)

1
14 importance ix i
1
15 sensitivity ix i
2 3
16 auto-forwarded c m
17 extensions m m
4
17.1 incomplete-copy c m
17.2 languages m m
5
17.3 primary-precedence mr m
6
17.4 copy-precedence mr m
17.5 message-type mr m
17.5.1 type mr m
17.5.2 identifier m m
17.6 address-list-indicator o m
17.6.1 type m m
17.6.2 list-name m m
17.6.3 notification-request m m
17.6.4 reply-request m m
17.7 exempted-address m m
17.8 extended-authorisation-info m m
17.9 distribution-codes m m
17.9.1 sics m m
17.9.2 dist-extensions m m
17.10 message-instructions m m
7
17.11 codress-message o o
17.12 originator-reference m m
Orig. Rec.
17.13 other-recipient-indicator m m
17.13.1 type m m
17.13.2 designator m m
7
17.14 handling-instructions o o
7
17.15 pilot-forwarding-info o o
17.15.1 pilot-precedence m m see B.1.5(4)
17.15.2 pilot-recipient m m see B.1.5(2)
17.15.3 pilot-security m m
17.15.4 pilot-handling m m
7
17.16 acp127-message-identifier o o
7
17.17 originator-plad o o
Notes:
1 This protocol element shall not be prompted for or displayed at the user interface. It shall not be
originated and if received may be ignored.
2 Support for auto-forwarding is dependent on local policy and may be influenced by security policies.
3 If the implementation supports autoforwarding then m, else o.
4 During forwarding, if the implementation allows elements of the forwarded message to be omitted
then m, else o.
5 Presence of this element is required in a message if and only if primary recipients are specified in the
message.
6 Presence of this element is required in a message if and only if copy recipients are specified in the
message.
7 These elements are for support of EoS that are only needed to support the ACP127 FG.
Note: The additional heading extension body-part-security-label may be added here subject to approval of a
pending change proposal to STANAG 4406.
B.1.3 MM body
Orig. Rec.
1 ia5-text m m
1.1 parameters m m
1.1.1 repertoire m m
1.2 data m m
2 voice o m
2.1 parameters i i
2.2 data m m
Orig. Rec.
3 g3-facsimile o o
3.1 parameters m m
3.1.1 number-of-pages o m
3.1.2 non-basic-parameters o m
3.1.2.1 two-dimensional o m
3.1.2.2 fine-resolution o m
3.1.2.3 unlimited-length o o
3.1.2.4 b4-length o o
3.1.2.5 a3-width o o
3.1.2.6 b4-width o o
3.1.2.7 uncompressed o o
3.2 data m m
4 g4-class-1 o o
5 teletex o o
5.1 parameters m m
5.1.1 number-of-pages o m
5.1.2 telex-compatible o m
5.1.3 non-basic-parameters o m
5.2 data m m
6 videotex o o
6.1 parameters m m
6.1.1 syntax o m
6.2 data m m
7 encrypted o m
7.1 parameters i i
7.2 data m m
8 message m m
8.1 parameters m m
8.1.1 delivery-time m m
8.2 data m m
8.2.1 IPM m m
9 mixed-mode o o
10 bilaterally-defined o o
11 nationally-defined o o
Orig. Rec.
1
12 externally-defined m m see B.1.3.1
Note:
1 It shall be stated in the IO-ICS whether any other specific extended body part types are supported.
B.1.3.1 Extended body part support
Orig. Rec.
1 ia5-text-body-part m m see B.1.3(1)
2 g3-facsimile-body-part o o see B.1.3(3)
3 g4-class-1-body-part o o see B.1.3(4)
4 teletex-body-part o o see B.1.3(5)
5 videotex-body-part o o see B.1.3(6)
6 encrypted-body-part o m
6.1 parameters o o
6.2 data m m
7 message-body-part m m see B.1.3(8)
1
11 general-text-body-part m m
2
12 file-transfer-body-part m m
13 voice-body-part o o
13.1 parameters o o
13.2 data m m
14 oda-body-part o o
15 adatp3-body-part m m
15.1 parameters m m
15.2 data m m
3
16 corrections-body-part o o
16.1 parameters o m
16.2 data o m
17 forwarded-encrypted-body-part o m
17.1 parameters m m
Orig. Rec.
17.2 data m m
18 mm-message-body-part m m
18.1 parameters m m
18.2 data m m
3
19 acp127Data-body-part o o
19.1 parameters o m
19.2 data o m
20 forwarded-CSP-Message-Body-Part m m
Notes:
1 It shall be stated in the IO-ICS which character repertoires are supported for support of the general-
text body-part type.
2 Expansion of the sub-components of this body part is anticipated for future revisions, based on
developments in commercial profiles.
Note: The additional body parts forwarded-report-body-part, forwarded-notification-body-part, and server-

query-body-part may be added here subject to approval of a pending change proposal to STANAG 4406.
B.1.3.2 General text repertoire support
Ref Repertoire set description Repetoire Profile

identifier(s)
Orig. Rec.
1 Basic (ISO 646) {1,6} m m
2 Basic-1 (ISO 8859-1) {1,6,100} m m
7 Basic + Korean {1,6,149} o o
8 Basic-1 + Cryillic (ISO 8859-5) {1,6,100,144} o o
9 Basic-1 + Arabic (ISO 8859-6) {1,6,100,127} o o
10 Basic-1 + Greek (ISO 8859-7) {1,6,100,126} o o
11 Basic-1 + Hebrew (ISO 8859-8) {1,6,100,138} o o
12 Full Latin (1) {1,6,100,154} o o
13 Full Latin (2) (ISO 6937) {1,6,156} o o
14 Teletex Basic Latin (T.61) {102,103,106,107) o o
B.1.4 MN fields
Orig. Rec.
1 subject-ipms m m see B.1.5(3)
2 ipn-originator m m see B.1.5(2)
3 ipm-preferred-recipient m m see B.1.5(2)
5 notification-extensions i i
1
6 non-receipt-fields c m
6.1 non-receipt-reason m m
6.2 discard-reason m m
2
6.3 auto-forward-comment c m
6.4 returned-ipm ix i
6.5 nrn-extensions i i
7 receipt-fields m m
7.1 receipt-time m m
7.2 acknowledgment-mode m m
7.2.1 manual m m
7.2.2 automatic o m
7.3 suppl-receipt-info o o
7.4 rn-extensions i i
8 other-notification-type-fields o o
3
8.1 acp127-notification-response i o
8.1.1 acp127-notification-type i o
8.1.2 receipt-time i o
8.1.3 addressListInicator i o
8.1.4 acp127-recipient i o
8.1.5 acp127-supp-info i o
Notes:
1 If any of the base standard conditions for Non-receipt can occur then support of this element is m,
else o.
2 If auto-forwarding is supported then support of this element is m, else o.
B.1.5 Common data types
Orig. Rec.
1 RecipientSpecifier
1.1 recipient m m see B.1.5(2)
1.2 notification-requests m m
1.2.1 rn m m
1.2.2 nrn m m
1.2.3 ipm-return ix i
1.3 reply-requested m m
1.4 recipient-extensions o o
1
1.4.1 acp127-notification-request o i
2 ORDescriptor
2.1 formal-name m m see B.1.5(5)
2.2 free-form-name m m
2.3 telephone-number o m
3 IPMIdentifier
3.1 user m m see B.1.5(5)
3.2 user-relative-identifier m m
4 MMHSPrecedence
4.1 deferred (0) o m
4.2 routine (1) m m
4.3 priority (2) m m
4.4 immediate (3) m m
4.5 flash (4) m m
4.6 override (5) o m
4.7 nato-reserved (6-15) i i
4.8 nationally defined (16-30) i i
5 ORName
5.1 mnemonic O/R address m m
5.2 numeric O/R address m m
5.3 terminal O/R address o o
5.4 formatted postal O/R address o o
Orig. Rec.
5.5 unformatted postal O/R address o o
5.6 directory-name m m
Note:
B.2 Optional functional groups
The following requirements are additional to those specified in B.1 if support of the functional groups is
claimed.
B.2.1 ACP 127 Interworking (ACP127)
B.2.1.1 ACP 127 Interworking (ACP127) MM heading fields
Ref Element Profile
Orig. Rec.
17.11 codress-message m
17.14 handling-instructions m
17.15 pilot-forwarded m
17.16 acp127-message-identifier m
17.18 originator-plad m
B.2.1.2 ACP 127 Interworking (ACP127) MM body
Ref Element Profile
Orig. Rec.
16 correction-body-part m
19 acp127Data-body-part m
B.3 Additional Information
B.3.1 MM Elements of Service support
The table in ACP 123, annex B, appendix A, clause 8.1.1, shall be completed to indicate, for each MM
Element of Service, whether it is available to the MHS user and, if so, how this is achieved. For each
EoS for which support is claimed, the implementor will check the column which indicates how the EoS is
supported in a given instance. If appropriate the Comments column can be filled in to provide additional
information as to how the EoS is selected.
ACP 123 goes beyond X.400 by stating which MM Elements of Service are to be supported as user
1 ACP127 Message Identifier D
2 ACP127 Notification Request
3 ACP127 Notification Response D
4 Authorizing Users Indication sD
5 Auto-forwarded Indication D
6 Blind Copy Recipient Indication sD1
7 Body Part Encryption Indication D
8 Clear Service D2
9 Codress Message indicator D
10 Copy Precedence sD3
11 Corrections D
12 Cross-referencing Indication sD
13 Distribution Code sD
14 Exempted Addresses sD
15 Expiry Date Indication sD
16 Extended Authorization Info sD
17 Forwarded Message Indication sD
18 Handling Instructions D
19 Importance Indication
10
20 Incomplete Copy Indication s D
21 Language Indication sD
22 Message Instructions sD
23 Message Type sD4
24 IPM-message Identification D
25 Multi-part Body sD
26 Non-receipt Notification Request Indication sD5
27 Obsoleting Indication sD
28 Originator Indication D
29 Originator Reference sD
30 Originator PLAD
31 Other Recipient Indicator sD
32 Pilot Forwarded D
33 Primary and Copy Recipients Indication sD6
34 Primary Precedence sD7
35 Receipt Notification Request Indication sD8
36 Reply Request Indication sD9
37 Replying Message Indication sD
38 Sensitivity Indication
39 Subject Indication sD
40 Typed Body
41 Use of Address List sD
Notes:
1 If this recipient is a BCC recipient the indication must be immediately displayed to the user
without explicit user command when the message is read.
2 If the Clear Service Indication is present, the phrase "RECEIVED IN THE CLEAR, TREAT
AS CONFIDENTIAL" must be immediately displayed to the user when the message is read.
3 If a recipient is a Copy recipient, the Copy Precedence must be immediately displayed
4 If Message Type is present, the associated information must be immediately displayed to the
user without requiring explicit user command when the message is read.
5 If a non-receipt notification is received, the information associated with it must be displayable
to the user.
6 A recipient must immediately see an indication of whether he/she is specified as a Primary or
Copy recipient for the message without requiring explicit user command when the message
is read. Additional action may be required to display other Primary and Copy recipients.
7 If a recipient is a Primary recipient, the Primary Precedence must be immediately displayed
8 If Receipt Notification was requested, this must be displayed to the user without explicit user
command when the message is read.
9 If Reply was requested, this must be displayed to the user without explicit user command
when the message is read.
10 Must make available to user if forwarding of incomplete messages is supported.
B.3.2 Encoded information type conversion requests supported
It shall be stated in the IO-ICS, which encoded information type conversion request the implementation
supports.
B.3.3 Non-standard integer body part types supported
It shall be stated in the IO-ICS, which non-standard integer body part types the implementation supports.
B.3.4 Extended body part types supported
It shall be stated in the IO-ICS, which extended body part types implementation supports.
B.3.5 General text body part repertoire support
It shall be stated in the IO-ICS, which general text body part repertiore the implementation supports.
UNCLASSIFIED ANNEX E to ACP 123
ANNEX E
TITLE: Information technology – Standardized Profiles –

Military Message Handling Systems – Message Store Attributes
FMH20(D) – General MS Attributes
This document is a Standardized Profile (SP) for Military Message Handling System
(MMHS) requirements for general Message Store (MS) attributes. It is outside the scope
of the current Taxonomy Framework for International Standardized Profiles (ISP). This
SP is a content-independent profile for the general MS attributes as defined in CCITT
Rec. X.413 (1992) | ISO/IEC 10021-5 (1990).
UNCLASSIFIED E-1 ORIGINAL

Introduction
FMH20(D) covers information representation by Military Messaging User Agents (MM-UA) and Military
Messaging Message Stores (MM-MS). It specifies support of the general MS attributes defined in CCITT
Rec. X.413 (1992) | ISO/IEC 10021-5 (1990).
FMH20(D) contains one normative appendix:
Appendix A SPICS Requirements List for FMH20(D)


Message Handling Systems – Message Store Attributes
FMH20(D) – General MS Attributes
1 Scope
1.1 General
FMH20(D) covers the representation of information, specifically MS attributes, by MM-MSs and MM-
UAs.
FMH20(D) specifies the profile which states requirements for general MS Attributes.
1.3 Scenario
The model used is one of information representation of MS attributes by the MM-MS and MM-UA (see
figure 1).
MS Attributes
MM-UA MM-MS
P7
Figure 1 – FMH20(D) Scenario
There are no Open System Interconnection (OSI) upper layer services and protocols within the scope of
the FMH20(D) profile.
2 References
Technical corrigenda to the base standards referenced are listed in appendix B of ISO/IEC 10611-5.

ISO/IEC 10021-1: 1990, Information technology – Text Communication – Message-Oriented Text

Interchange Systems (MOTIS) – Part 1: Service Overview. [see also CCITT Recommendation
X.400(1992)]

Interchange Systems (MOTIS) – Part 2: Overall Architecture. [see also CCITT Recommendation
X.402(1992)]
SO/IEC 10021-5: 1990, Information technology – Text Communication – Message-Orientated Text

Interchange Systems (MOTIS) – Part 5: Message Store: Abstract Service Definition. [see also CCITT
Recommendation X.413 (1992)]
CCITT Recommendation X.400(1992), Message handling system and service overview.
CCITT Recommendation X.402(1992), Message handling systems: Overall architecture.
CCITT Recommendation X.413(1992), Message handling systems: Message store: Abstract service
definition.
Netherlands.)
3 Definitions
the referenced base standard. In addition, the following terms are defined.
3.1 General
Base standard : the base standard referred to in this profile is the X.413 recommendation.
Basic requirement : a general MS attributes specified in the base standard which is required to be
supported by all MMHS implementations conforming to this SP.
To specify the support level of features for FMH21(D), the following terminology is defined.

The following classification is used in FMH20(D) to specify static conformance requirements – i.e.,
capability.
the ability to handle both the syntax and semantics of the element) as relevant, as specified in the base
standard. Where support for generation and reception are not distinguished, then both capabilities shall
be assumed.
the element shall be treated as if it were specified as mandatory support. If support for generation is not
implementation may ignore the element on reception, but will not treat it as an error.

CCITT International Telephone and Telegraph Consultative Committee
ISPICS International Standardized Profiles Implementation Conformance Statement
MM Military Message
MS Message Store
UA User Agent

o optional support
5 Conformance
The scope of conformance to profile FMH20(D) covers MM-MSs and MM-UAs only. Conformance to
profile FMH20(D) does not imply the provision of a standard OSI communications protocol for access to
the Message Transfer System (MTS).


to FMH20(D) is a claim that all requirements in the relevant base standard are satisfied, and that all
requirements in the following clauses and in appendix A of FMH20(D) are satisfied. Appendix A states
the relationship between these requirements and those of the base standard.
For each implementation claiming conformance to profile FMH20(D), an International Standard Profiles
Implementation Conformance Statement (ISPICS) shall be made available stating support or non-
support of each option identified FMH20(D). The ISPICS Proforma in ISO/IEC 10611-5 shall be used to
generate the ISPICS.

Appendix A
(normative)

appear in the implementation columns of a ISPICS.
Clause A.1 specifies the basic requirements for conformance to profile FMH20(D).
A.1.1 General Attributes
Ref Attribute UA MS
1 ms-child-sequence-numbers o m
2 ms-content m m
3 mt-content-confidentiality-algorithm-identifier o o
4 mt-content-correlator o m
5 mt-content-identifier o m
6 mt-content-integrity-check o o
7 ms-content-length o m
8 ms-content-returned o m
9 content-type m m
10 conversion-with-loss-prohibited o m
11 ms-converted-eits o m
12 ms-creation-time o m
13 ms-delivered-eits o m
14 delivery-flags o m
15 dl-expansion-history o m
16 entry-status m m
17 entry-type o m
18 intended-recipient-name o m
19 message-delivery-envelope m m
20 message-delivery-identifier o m
(Appendix A to Annex E)
Ref Attribute UA MS
21 mt-message-delivery-time o m
22 message-origin-authentication-check o o
23 message-security-label o o
24 message-submission-time o m
25 message-token o o
26 original-eits o m
27 originator-certificate o o
28 originator-name m m
29 other-recipient-names o m
30 parent-sequence-number o m
31 per-recipient-report-delivery-fields o m
32 mt-priority o m
33 proof-of-delivery-request o o
34 redirection-history o m
35 report-delivery-envelope m m
36 reporting-dl-name o m
37 reporting-mta-certificate o o
38 report-origin-authentication-check o o
39 security-classification o o
40 sequence-number m m
41 subject-submission-identifier o m
42 this-recipient-name o m
(Appendix A to Annex E)
UNCLASSIFIED ANNEX F to ACP 123
ANNEX F
TITLE: Information technology – Standardized Profiles –

Military Message Handling Systems – Message Store Attributes
FMH21(D) – MM-specific MS Attributes
This document is a Standardized Profile (SP) for Military Message Handling System
(MMHS) requirements for Military Message (MM) specific Message Store (MS)
attributes. It is outside the scope of the current Taxonomy Framework for International
Standardized Profiles (ISP). This SP is a profile of the MM-specific MS attributes as
defined in the Allied Communication Publication (ACP) 123.
UNCLASSIFIED F-1 ORIGINAL

Introduction
FMH21(D) covers information representation by Military Messaging User Agents (MM-UA) and Military
Messaging Message Stores (MM-MS). It specifies support of the MM-specific attributes defined in ACP
123.
FMH21(D) contains one normative appendix:
Appendix A SPICS Requirements List for FMH21(D)


Message Handling Systems – Message Store Attributes
FMH21(D) – MM-specific MS Attributes
1 Scope
1.1 General
FMH21(D) covers the representation of information, specifically MS attributes, by MM-MSs and MM-
UAs.
FMH21(D) specifies the profile which states requirements for MM-specific MS Attributes.
1.3 Scenario
The model used is one of information representation of MM-specific MS attributes by the MM-MS and
MM-UA (see figure 1).
MS Attributes
MM-UA MM-MS
P7
Figure 1 – FMH21(D) Scenario
There are no Open System Interconnection (OSI) upper layer services and protocols within the scope of
the FMH21(D) profile.
2 References
Technical corrigenda to the base standards referenced are listed in annex B, appendix B of ACP 123.

ISO/IEC 8859: 1990, Information processing – 8-bit single-byte coded graphic character sets.
ISO/IEC 8613-1: 1993, Information processing – Text and office systems – Open Document Architecture
(ODA) and interchange format – Part 1: Introduction and general principles.

Interchange Systems (MOTIS) – Part 1: Service Overview. [see also CCITT Recommendation
X.400(1992)]

Interchange Systems (MOTIS) – Part 2: Overall Architecture. [see also CCITT Recommendation
X.402(1992)]
ISO/IEC 10021-5: 1990, Information technology – Text Communication – Message-Orientated Text

Interchange Systems (MOTIS) – Part 5: Message Store: Abstract Service Definition. [see also CCITT
Recommendation X.413 (1992)]
CCITT Recommendation X.400(1992), Message handling system and service overview.
CCITT Recommendation X.402(1992), Message handling systems: Overall architecture.
CCITT Recommendation X.413(1992), Message handling systems: Message store: Abstract service
definition.
Netherlands.)
3 Definitions
the referenced base standards. In addition, the following terms are defined.
3.1 General
MM base standard : the base standard referred to in this profile is ACP 123.
Basic requirement : an MM-specific MS attribute which is required to be supported by all MMHS

implementations conforming to this SP.
Functional group : a specification of one or more related MM-specific MS attributes specified in the
base standard which together support a significant optional area of functionality.

To specify the support level of features for FMH21(D), the following terminology is defined.
The following classifications are used in FMH21(D) to specify static conformance requirements – i.e.,
capability.
the ability to handle both the syntax and semantics of the element) as relevant, as specified in the MM
base standard. Where support for generation and reception are not distinguished, then both capabilities
shall be assumed.
the element shall be treated as if it were specified as mandatory support. If support for generation is not
implementation may ignore the element on reception, but will not treat it as an error.
out of scope (i) : the element is outside the scope of FMH21(D) – i.e., it will not be the subject of a SP
conformance test.

CCITT International Telephone and Telegraph Consultative Committee
FG Functional group
MM Military Message
MS Message Store
UA User Agent


o optional support
i out of scope
5 Conformance
The scope of conformance to profile FMH21(D) covers MM-MSs and MM-UAs only. Conformance to
profile FMH21(D) does not imply the provision of a standard OSI communications protocol for access to
the Message Transfer System (MTS).

to FMH21(D) is a claim that all requirements in the relevant base standard are satisfied, and that all
requirements in the following clauses and in appendix A of FMH21(D) are satisfied. Appendix A states
the relationship between these requirements and those of the base standard.
For each implementation claiming conformance to profile FMH21(D), an Information Object Information
Implementation Conformance Statement (IO-ICS) shall be made available stating support or non-support
of each option identified FMH21(D). The IO-ICS Proforma in annex B of ACP 123 shall be used to
generate the IO-ICS.

Appendix A
(normative)

appear in the implementation columns of an IO-ICS.
Clause A.1 specifies the basic requirements for conformance to profile FMH21(D) (reference numbers
correspond to items in the IO-ICS). Clause A.2 specifies the additional requirements if support of the
ACP 127 FG is claimed.
A.1.1 MM-specific Attributes
Ref Element Profile
UA MS
1 acknowledgment-mode o m
2 authorizing-users o m
3 auto-forward-comment o m
4 auto-forwarded o m
5 bilaterally-defined-body-parts o o
6 blind-copy-recipients o m
7 body m m
9 copy-recipients o m
10 discard-reason o m
11 encrypted-body-parts o o
12 encrypted-data o o
13 encrypted-parameters o o
14 expiry-time o m
1
15 extended-body-part-types m m
16 g3-facsimile-body-parts o o
17 g3-facsimile-data o o
(Appendix A to Annex F)
Ref Element Profile
UA MS
18 g3-facsimile-parameters o o
19 g4-class1-body-parts o o
20 heading m m
21 ia5-text-body-parts o m
22 ia5-text-data o o
23 ia5-text-parameters o o
24 importance i i
25 incomplete-copy o m
26 ipm-entry-type m m
27 ipm-preferred-recipient o m
28 ipm-synopsis o m
29 ipn-originator o m
30 languages o m
31 message-body-parts o m
32 message-data o o
33 message-parameters o o
34 mixed-mode-body-parts o o
35 nationally-defined-body-parts o o
36 non-receipt-reason o m
37 nrn-requestors o m
38 obsoleted-mms o m
39 originator o m
40 primary-recipients o m
41 receipt-time o m
42 related-mms o m
43 replied-to-ipm o m
44 reply-recipients o m
45 reply-requestors o m
46 reply-time o m
47 returned-ipm o o
48 rn-requestors o m
49 sensitivity i i
50 subject o m
51 subject-ipm m m
52 suppl-receipt-info o o
Ref Element Profile
UA MS
53 teletex-body-parts o o
54 teletex-data o o
55 teletex-parameters o o
56 this-ipm m m
57 videotex-body-parts o o
58 videotex-data o o
59 videotex-parameters o o
60 voice-body-parts o o
61 voice-data o o
62 voice-parameters o o
63 acp127-message-identifier o o
64 address-list-indicator o o
65 codress-message o o
66 copy-precedence m m
67 distribution-codes m m
68 exempted-address m m
69 extended-authorisation-info m m
70 handling-instructions o o
71 message-instructions m m
72 message-type m m
73 originator-reference o m
74 originator-plad o o
75 other-recipients-indicator o m
76 pilot-forwarding-info o o
77 primary-precedence m m
78 acp-127-notification-request o o
79 acp127-notification-response o o
Notes:
1 See table A.1.2.1 for extended-body-part-types
A.1.1.1 Extended body part support
Ref Element Profile
UA MS
1 ia5-text-body-part m m
2 g3-facsimile-body-part o o
3 g4-class-1-body-part o o
4 teletex-body-part o o
5 videotex-body-part o o
6 encrypted-body-part i i
7 message-body-part m m
11 general-text-body-part m m
12 file-transfer-body-part m m
13 voice-body-part i i
14 oda-body-part o o
15 aDatP3-body-part m m
16 corrections-body-part o o
17 forwarded-encrypted-body-part o m
18 mm-message-body-part m m
19 acp127data-body-part o o
A.2 Optional functional groups
The following requirements are additional to those specified in A.1 support of the optional ACP 127 FG is
claimed (references are to the corresponding entries in A.1).
A.2.1 ACP 127 Interworking (ACP127) MM-specific Attributes
Ref Element Profile
UA MS
63 acp127-message-identifier m
65 codress-message m
74 originator-plad m
76 pilot-forwarding-info m
78 acp-127-notification-request m
79 acp127-notification-response m
UNCLASSIFIED F - 10 ORIGINAL
UNCLASSIFIED ANNEX G to ACP 123
Annex G
REFERENCE DOCUMENTS
STANAG 4406: Military Message Handling System, Edition 2, October, 1995
Military Message Handling System (MMHS) Ad-hoc Working Group (AHWG) Rationale Document, Issue:
U, 6 September, 1993.
The International Telegraph and Telephone Consultative Committee (CCITT)1, September 1992, Data
Communication Networks Message Handling Systems Recommendations X.400-X.420
The International Telegraph and Telephone Consultative Committee (CCITT)1, February 1993, Data
Communication Networks Directory Recommendations X.500-X.525
ITU Special Rapporteur's Group on Message Handling Systems (Q14/VII) and ISO/IEC JTC 1/SC 18/WG
4 SWG on Messaging, July 1994, MHS Implementors' Guide Version 11
ISO/IEC 8613-1: 1993, Information technology – Open Document Architecture (ODA) and Interchange
Format – Part 1: Introduction and general principles
ISO/IEC 8824: 1990, Information processing systems – Open Systems Interconnection – Specification of
Abstract Syntax Notation One (ASN.1)
ISO/IEC 8859: 1992, Information technology – 8-bit single-byte coded graphic character sets
ISO/IEC 9646-1: 1991, Information technology – Open Systems Interconnection – Conformance Testing
Methodology and Framework Part 1: General concepts
ISO/IEC 9646-7: 1992 Information Technology – Open Systems Interconnection – Conformance Testing
Methodology and Framework Part 7: Implementation Conformance Statements
ISO/IEC 10021 parts 1-7 Information technology – Text Communication – Message-Oriented Text
Interchange Systems (MOTIS)
ISO/IEC ISP 10611 parts 1-5 International Standardized Profiles AMH1n - Message Handling Systems -
Common Messaging
ACP 198( ) Instructions for the Preparation of Communications-Electronics Publications
ACP 120( ) Common Security Protocol
ACP 121( ) Communication Instructions General
ACP 126( ) Communication Instructions - Teletypewriter (Teleprinter) Procedures
ACP 127( ) Communication Instructions - Tape Relay Procedures
1
Note that CCITT is now known as the International Telecommunications Union -
Telecommunications Standardization Sector (ITU-T).
UNCLASSIFIED G-1 ORIGINAL

UNCLASSIFIED ANNEX G to ACP 123
ACP 131( ) Communication Instructions - Operating Signals
ACP 133() Common Directory Service and Procedures
Final ACP 123 Scope Document, May 29, 1991
ACP 123 Requirements Document Update #7, February, 1993
A Recommended Framework for the Development of ACP 123, March 22, 1991
UNCLASSIFIED G-2 ORIGINAL

UNCLASSIFIED LEP for ACP 123
UNCLASSIFIED LEP-1 ORIGINAL

(Reverse Blank)

Acp 123

Uploaded by

Copyright:

Available Formats

Acp 123

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Acp 123

Uploaded by

Copyright:

Available Formats

What is the purpose of this document?

What is the purpose of this document?

What standards does this document reference?

What standards does this document reference?

UNCLASSIFIED ACP 123(A)

1. ACP 123, COMMON MESSAGING STRATEGY AND PROCEDURES, is an UNCLASSIFIED

UNCLASSIFIED III ORIGINAL

RECORD OF CHANGES AND CORRECTIONS

Enter Change or Correction in Appropriate Column

UNCLASSIFIED VII ORIGINAL

RECORD OF CHANGES AND CORRECTIONS

Enter Change or Correction in Appropriate Column

UNCLASSIFIED VIII ORIGINAL

RECORD OF PAGES CHECKED*

*THIS PAGE NOT APPLICABLE TO US HOLDERS

RECORD OF PAGES CHECKED*

*THIS PAGE NOT APPLICABLE TO US HOLDERS

UNCLASSIFIED XII ORIGINAL

UNCLASSIFIED XIII ORIGINAL

UNCLASSIFIED XIV ORIGINAL

Military Messaging Content Type ...................................................................................... A - 1

MM IO-ICS Proforma ........................................................................................................... B - 1

STANDARDIZED PROFILE: AMH1n(D)

STANDARDIZED PROFILE: FMH11(D)

STANDARDIZED PROFILE: FMH20(D)

STANDARDIZED PROFILE: FMH21(D)

LIST OF EFFECTIVE PAGES

List of Effective Pages .................................................................................................... LEP - 1

UNCLASSIFIED XVI ORIGINAL

UNCLASSIFIED 1-1 ORIGINAL

a. The fundamental purpose of ACP 123 is to define a common message service to be

UNCLASSIFIED 1-2 ORIGINAL

d. The MMHS Management Domains may be connected to Civilian MHS Management

UNCLASSIFIED 1-3 ORIGINAL

IPMS Heading Fields

Figure 1-1 X.400/ACP 123 Message Structure

UNCLASSIFIED 1-4 ORIGINAL

ACP 123 Military Message

ACP 133 Directory System

Figure 1-2 ACP 123 Messaging Environment

UNCLASSIFIED 1-5 ORIGINAL

Figure 1-3 ACP 123 Management Domain Connections

UNCLASSIFIED 1-6 ORIGINAL

105. Structure of the Document

UNCLASSIFIED 1-7 ORIGINAL

i. Dynamic – Dynamic behavior characterizes the constraints on the use of an element of

k. Formal military message – A formal military message is a message sent on behalf of an

UNCLASSIFIED 1-8 ORIGINAL

m. MM – Military Message – The MM is an information object supported by ACP 123 that is

t. Plain Language Address Designator (PLAD) – A PLAD is an abbreviated or non-abbreviated

u. Precedence – Precedence is a labeled value that reflects the originator's determination of

4 Guidelines for individual traffic shall be clarified in supplements or by bilateral agreements.

UNCLASSIFIED 1-9 ORIGINAL

z. Static – Static behavior characterizes the capability of an implementation to support (i.e.,

aa. Translation Gateway – A translation gateway is a component that translates between

ACP Allied Communication Publication

IPM Interpersonal Message

PLAD Plain Language Address Designator