|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
DoD Common Messaging System
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
COMMON MESSAGING STRATEGY AND PROCEDURES
ACP 123
NOVEMBER 1994
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.
OFFICE OF THE CHAIRMAN
JOINT CHIEFS OF STAFF
WASHINGTON, D.C. 20318-0001
Reply ZIP Code: ACP 123
20318-0400 14 November 1994
US NATIONAL LETTER OF PROMULGATION
FOR ACP 123
1. The purpose of this US National Letter of Promulgation is to
implement ACP 123 within the Armed Forces of the United States.
ACP 123, COMMON MESSAGING STRATEGY AND
PROCEDURES, is an UNCLASSIFIED publication developed for
allied use and, under the direction of the Chairman of the Joint
Chiefs of Staff, is promulgated for guidance, information, or use of
the Armed Forces of the United States and other users of US
military communications facilities.
2. The effective status of this publication will be shown below:
EFFECTIVE ACTIVE STATUS
Publication
Effective For
Date
Authority
ACP 123
US
1 Jan 95
LOP
ACP 123
NATO
1 Jan 95
LOP
3. Correspondence concerning this publication should be addressed
as follows:
a. Service-originated correspondence will be forwarded through the
normal military chain of command, marked for the attention of the
appropriate Service commununications chief or director, as listed
below, and will not be addressed to the Joint Staff:
(1) Director of Information Systems for Command, Control,
Communications, and Computers, US Army.
(2) Director, Space and Electronic Warfare (N-6), US Navy.
(3) Deputy Chief of Staff, Command. Control, Communications
and Computers, US Air Force.
(4) Assistant Chief of Staff, Command, Control, Communications,
Computers and Intelligence, US Marine Corps.
b. Defense, National, and Federal agencies, as well as other
recipients of this publication, should address their correspondence
to the Chairman, Military Communications-Electronics Board,
Joint Staff, Pentagon, Washington, D.C. 20318-6100.
For the Chairman of the Joint Chiefs of Staff:
T. R. PATRICK
Colonel, USA
Secretary, Joint Staff
RECORD OF CHANGES AND CORRECTIONS
Enter Change or Correction in Appropriate Column
Identification of Change or Correction and Date of Same Date
Entered
By Whom Entered (Signature; rank, grade or rate; name of
command) Change
Correction
RECORD OF CHANGES AND CORRECTIONS
Enter Change or Correction in Appropriate Column
Identification of Change or Correction and Date of Same Date
Entered
By Whom Entered (Signature; rank, grade or rate; name of
command) Change
Correction
RECORD OF PAGES CHECKED
Date Checked By Whom Checked (Signature and Rank) Date
Checked By Whom Checked (Signature and 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.
RECORD OF PAGES CHECKED
Date Checked By Whom Checked (Signature and Rank) Date
Checked By Whom Checked (Signature and 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.
Table of Contents
Foreword III Letter of Promulgation V Record of Changes and
Corrections VII Record of Pages Checked IX Table of Contents XI
List of Figures XVICHAPTER 1GENERALSECTION
IINTRODUCTION 101. Background 1-1 102. Evolution 1-1 103.
Scope 1-2 104. Overview 1-2 105. Structure of the Document 1-3
SECTION II DEFINITION OF TERMS USED IN THIS
PUBLICATION 106. Definitions 1-8 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-
2 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-message identification 2-2 f. Message identification 2-3 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-3 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-4 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-5 k.
Deferred delivery cancellation 2-5 l. Delivery notification 2-5 m.
Designation of recipient by directory name 2-6 n. Disclosure of
other recipients 2-6 o. DL expansion history indication 2-6 p. DL
expansion prohibited 2-6 q. Expiry date indication 2-6 r. Explicit
conversion 2-7 s. Forwarded MM-message indication 2-7 t. Grade
of delivery selection 2-7 u. Hold for delivery 2-7 v. Incomplete
copy indication 2-7 w. Language indication 2-8 x. Latest delivery
designation 2-8 y. Multi-destination delivery 2-8 z. Multi-part body
2-8 aa. Non-receipt notification request indication 2-8 ab.
Obsoleting indication 2-8 ac. Originator indication 2-8 ad.
Originator requested alternate recipient 2-9 ae. Prevention of non-
delivery notification 2-9 af. Primary and copy recipients indication
2-9 ag. Receipt notification request indication 2-9 ah. Redirection
disallowed by originator 2-9 ai. Redirection of incoming messages
2-10 aj. Reply request indication 2-10 ak. Replying MM indication
2-10 al. Requested delivery method 2-10 am. Subject indication 2-
10 an. Use of distribution list 2-10 203. Optional IPMS Elements
of Service not used in MMHS 2-11 a. Implicit conversion 2-11 b.
Importance indication 2-11 c. Probe 2-11 d. Restricted delivery 2-
11 e. Return of content 2-11 f. Sensitivity indication 2-12 204.
Physical Delivery Elements of Service 2-12 205. Security Elements
of Service 2-12 206. Message Store Elements of Service 2-12 a.
MS register 2-12 b. Stored message alert 2-12 c. Stored message
auto-forward 2-12 d. Stored message deletion 2-12 206.
(continued) e. Stored message fetching 2-13 f. Stored message
listing 2-13 g. Stored message summary 2-13 SECTION II
ADDITIONAL MILITARY ELEMENTS OF SERVICE 207.
Military Elements of Service 2-13 a. Primary Precedence 2-13 b.
Copy Precedence 2-13 c. Message Type 2-14 d. Exempted
addresses 2-14 e. Extended authorization info 2-14 f. Distribution
code 2-14 g. Message Instructions 2-14 h. Clear service 2-14 i.
Other recipient indicator 2-15 j. Originator reference 2-15 k. Use of
Address List 2-15 208. Transition Elements of Service 2-16 a.
Handling instructions 2-16 b. Pilot forwarded 2-16 c. Corrections
2-16 d. ACP127 Message Identifier 2-16 e. Originator PLAD 2-17
f. Codress message indicator 2-17 g. ACP 127 Notification
Request 2-17 h. ACP 127 Notification Response 2-17 CHAPTER
3 MESSAGE HANDLING SYSTEM COMPONENTS SECTION I
Message Transfer System 301. Submission Control to prohibit use
of Probes 3-1 302. Delivery and Non-Delivery Reports 3-1
SECTION II Military Messaging (MM) User Agents 305. Storage
and retrieval policies 3-2 SECTION III Message Stores 315. High
precedence messages and message alarms 3-2 316. High precedence
messages and autoforward 3-2 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. Signaling 4-2
c. Grade of Delivery 4-2 d. Determining Precedence 4-2 404.
Message Acknowledgment 4-2 405. Confirmation of Delivery 4-3
406. Cancellations 4-3 407. Corrections 4-3 408. Repetitions,
Checks, and Verifications 4-4 409. Minimize 4-4 410. Records 4-4
411. Tracer Action 4-5 412. Military Message Bodies 4-5 a.
Sequence of Textual Matter 4-5 b. Multiple Body Parts 4-5 c.
Military Body Part Types 4-5 413. Speed of Service 4-5 a. Speed
of Transmission 4-6 b. Speed of Handling 4-6 414. Duplicate
Detection 4-6 415. Conversion 4-6 416. References 4-7 417.
Exercise Communications 4-7 a. Exercise messages 4-7 b.
Identification of Exercise Message: 4-7 SECTION II SECURITY
420. Message confidentiality 4-8 421. Message integrity 4-8 422.
Data origin authentication 4-8 423. Access Control 4-8 424.
Message Non-repudiation with proof of origin 4-8 425. Message
Non-repudiation with proof of delivery 4-8 426. Message Security
Labeling 4-8 427. Accountability 4-8 428. Prohibition of Probes 4-
8 429. Security Classification 4-8 a. Responsibility 4-8 b.
Classifications 4-9 c. Security Label 4-9 SECTION III NAMING
AND ADDRESSING 435. O/R Addresses 4-9 436. Directory
Names 4-10 437. Address Lists 4-10 a. List Expansion 4-10 b.
Owner 4-10 c. Notifications 4-10 d. Titles 4-10 e. Use 4-11 438.
Directory Services 4-11 SECTION IV MANAGEMENT 440.
Accounting policies and procedures 4-11 441. Trace and
Accountability 4-11 442. Performance management 4-11 443.
Configuration management 4-12 CHAPTER 5 Profiles SECTION I
Standard Profile 501. Profile Definition 5-1 502. Additional
requirements on Elements of Service 5-1 a. Authorizing users
indication 5-1 b. Cross-Referencing indication 5-1 c. Designation
of recipient by directory name 5-1 d. Incomplete copy indication 5-
1 e. Language indication 5-1 f. Obsoleting indication 5-1
SECTION II Restricted Profile 505. Profile Definition 5-2 506.
Profile Components 5-2 a. Connectionless Communications 5-2 b.
Presentation-Layer Compression 5-2 c. Encoding Rules 5-3 d.
Addressing 5-3 Annex A Military Messaging Content Type A-1
Annex B Information Object Implementation Conformance
Statement Proforma B-1 Annex C Referenced Documents D-1
LIST OF EFFECTIVE PAGES List of Effective Pages LEP-1
List of Figures
Figure 1-1 X.400/ACP 123 Message Structure 1-4Figure 1-2 ACP
123 Messaging Environment 1-5Figure 1-3 ACP 123 Management
Domain Connections 1-6
CHAPTER 1
GENERAL
SECTION I
INTRODUCTION
a. The function of this document, 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, 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 Electronic 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
traffic. The new common messaging strategy, which includes the
definition of Elements of Service (EoS) and a corresponding set of
procedures, is based on the 1988 version of the International
Telegraph and Telephone Consultative Committee (CCITT) X.400
Recommendations.
b. This ACP identifies the service and protocol requirements
necessary to ensure interoperability among Military Message
Handling Systems (MMHS) for military message 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 NATO members, this ACP was developed in close
coordination with the NATO Tri-Service Group of
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.
Annex A is written in the structure and form of the 1988 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 the NATO STANAG 4406, in order to
ensure only one protocol definition for the support of the military
messaging content type.
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 102. (continued)
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 Elements of Service 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
formats and protocols. This does not, however, preclude national
differences for internal messaging.
b. Translation gateways will be required between ACP 123
domains and civilian MHS domains, as well as 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 is 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 must be displayed to the user, but the format of the
display is outside the scope of this document.
e. ACP 123 is based on the CCITT X.400 Message Handling
System (MHS) Recommendations (henceforth referred to as X.400)
and adopts the extensions made by the NATO STANAG 4406. This
document contains enough information to be read alone by
someone familiar with the X.400 Series Recommendations without
duplicating the majority of the material contained in those
documents. However, pointers to related information in the 1988
CCITT X.400 Series Recommendations are included for those
readers requiring more details. Pointers to related material
harmonized with STANAG 4406 refer to Annex A, which contains
military extensions to X.400. These extensions are presented in the
form of a delta document to the X.400 Recommendations.
f. The final ACP 123 document defines the services required in an
environment where messages are originated and received using
ACP 123. Nations exchanging military messages 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 services is therefore not required as part of
ACP 123. It is recognized that many of these same services will
need to be addressed in a transition document. These services are
defined as transition elements of service in paragraph 2.II.208.
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 104.
(continued)
automated writer-to-reader messaging system. X.400
Recommendations and protocols will be used for the exchange of
messages. Directory services should be provided to support
messaging system functions. It is recommended that directory
services and protocols conforming to the CCITT X.500 series of
recommendations be used. Because of the military environment,
some required extensions are specified by ACP 123. These
additional requirements include security, a military messaging user
agent, and a new content type.
b. Military messages are exchanged within X.400 envelopes. The
envelope contains the information necessary for transfer and
delivery of the message. This is analogous to postal systems, which
transfer a physical envelope and its contents and require specific
information on the outside of the envelope in order to ensure
delivery at the requested level of service. The content of the
envelope will be a Military Message (MM) content type, which is
an extension of the international standards and contains additional
information required for military communications. (See Figure 1-1)
The envelope is the same basic envelope as is used in international
MHS. This will enable commercial Message Transfer Systems
(MTS) to be used for carrying MMHS traffic.
c. The MMHS will be composed of a Message Transfer System
(MTS), User Agents (MM-UAs) to support the submission and
delivery of Military Messages, optional Message Stores (MS) to
assist a 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 used by X.400: P1, P3, and P7.
The P1 protocol supports communication between Message
Transfer Agents (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. Content
protocols, such as P22 and P772, are information objects that are
conveyed within the various envelope protocols. (See Figure 1-2)
d. The MMHS Management Domains will be connected to Civilian
MHS Management Domains by way of gateways if required.
During transition from older military messaging, ACP 123 domains
may also support gateways to older military messaging domains
(ACP 127). 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)
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 military messaging in an X.400
environment. The second chapter defines all the ACP 123 functions
in terms of Elements of Service. 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. Four annexes are included in this ACP. Annex A defines the
military messaging content type (MM) and has been harmonized
with NATO STANAG 4406, in order to ensure only one protocol
definition for the support of the military messaging content type.
Annex B is an Information Object
<Picture>Figure 1-1 X.400/ACP 123 Message Structure
<Picture>
Figure 1-2 ACP 123 Messaging Environment
<Picture>
Figure 1-3 ACP 123 Management Domain Connections
105.c (continued)
Implementation Conformance Statement 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 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 uniques 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 is the notation used for
abstractly defining the protocol data units used for exchanging
messaging information in X.400. (Defined in ISO 8824.)
b. Access Unit (AU) - The AU is an origination or delivery end
point that provides interconnection between indirect users of the
MMHS and direct users. Direct users are end users of Military
Messaging and indirect users are users of other types of messaging
services that can send messages to or receive messages from
MMHS users.
c. ACP 127 - ACP 127 is a generic designator used to refer to older
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.
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. Directory Name - A directory name is a unique identifier for a
record stored in a distributed directory system. A directory name
can be resolved by a directory system into a X.400 O/R Address, a
set of user capabilities, or other information. Note that while this
term is used extensively by the X.500 Directory Services
recommendations, the MMHS does not specifically require a
conformant X.500 directory. (See paragraph 436)
h. 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 ® - 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.
106. (Continued)
(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.
i. 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 committment on the part of that
organization, and that has been formally released in accordance
with the policies of the originating nation.
j. Gateway - Gateway is generic term that covers both access units
and translation gateways.
k. 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.
l. MM-AU - Military Messaging Access Unit - The MM-AU is a
functional object that links another communication system to the
MTS within an MMHS.
m. 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
Military Messages (MMs) on behalf of that user.
n. 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 that can generate and receive military messages.
o. MMHS - Military Message Handling System - The MMHS is the
messaging system defined by ACP 123. The purpose of MMHS is
to convey military messages among military organizations and
individuals. This document addresses only MMHS in the context
of military message traffic that has been approved for release
between military organizations.
p. 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.
q. 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.
r. 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).
s. Primary Recipients - Primary recipients are those recipients of a
message who have the responsibility to act on the delivered
message (action addressees).
t. Priority - Priority is a labeled value that reflects the required
speed of service for a message. It is synonomous with the Grade of
Delivery selection in the message transfer service.
106. (Continued)
u. 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).
v. 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 © - 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.
w. 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.
x. X.400 - X.400 is a generic designator used in this document to
refer to the international civilian standards, both the CCITT X.400
series of Recommendations and the corresponding ISO/IEC 10021
series (MOTIS).
107. Abbreviations
ACP Allied Communication Publication
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 Electronic Board
CCITT International Telegraph and Telephone Consultative
Committee
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
IPM Interpersonal Messaging
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
NDN Non-Delivery Notification
NRN Non-Receipt Notification
O/R Originator/Recipient
107. (Continued)
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
PLAD Plain Language Address Designator
RI Routing Indicator
SIC Subject Indicator Code
STANAG (NATO) Standardization Agreement
UA User Agent
USMTF U.S. Message Text Format
UTC Coordinated Universal Time
X.400 CCITT series of Recommendations on Message Handling
Systems
CHAPTER 2
MESSAGE SERVICES - ELEMENTS OF SERVICE
a. This chapter describes the services to be provided by ACP 123
using X.400 terminology. An Element of Service (EoS) is a
functional unit for describing a specific service feature provided by
the application. X.400 Elements of Service are listed with reference
to where they are defined in the CCITT X.400 Recommendations.
This is followed by a section listing the definition of additional
Elements of Service needed for a military environment. These
services, also defined by STANAG 4406, contain a reference to
their definition in Annex A. Some Elements of Service are only
required as long as there is a need to interoperate with the existing
messaging systems (ACP 127). These services are identified as
"transition elements of services" and are grouped in a separate
paragraph (2.II.208).
b. 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. Format lines carry specific
information in a known order. 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.
These data structures (protocol elements) describe information as it
is being transmitted between computers and are not always
character based or easily interpreted by the human user. X.400 and
related international standards describe distributed systems terms
of services provided and protocol exchanged. There is not
necessarily a one-to-one mapping between services and protocol
elements. Additionally, protocol addresses the format of data
transmitted between systems. It does not necessarily correspond
exactly to what is displayed on a user's terminal or printed on paper
when a message is converted to hard copy. Therefore the phrase
"Common Message Format" will not be used with ACP 123.
c. When an X.400 service is to be provided, it will be carried in the
corresponding protocol element as defined in X.400. Abstract
Syntax Notation One (ASN.1) is used to describe the data structure
or format of protocol elements as they are conveyed between
computers. Unless otherwise specified, the ASN.1 for protocol
elements is the same as defined in X.400 and is not duplicated
here. When a required service in the military context does not fit
one of the X.400 Elements of Service, a new service is defined.
New services will be carried in new protocol elements. The
description in this section 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 entire information objects defined
for the Military Messaging (MM) content type are found in Annex
A as the delta to Annex E of X.420. 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. The
international base standards refer to the CCITT X.400
Recommendations that are readily available and therefore not
duplicated here.
d. Requirements for the support of the services in the MMHS are
included in this document. In general, if a service is to be 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. 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. Elements of Service 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 the CCITT X.400
Recommendations, a short description is included with the name of
the EoS and a reference to its definition in X.400. If an EoS is said
to be supported, this means it must 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 Message Transfer Service
and enable a user to send and receive Military Messages (MMs).
All X.400 Basic EoS must be supported.
a. Access Management This element of service enables a User
Agent (UA) and Message Transfer Agent (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. (See X.400 B.1,
X.400 B.79)
b. Content type indication This element of service enables an
originating UA to indicate the content type for each submitted
message. Recipient UAs may be able to accept delivery of one or
more content types. Examples of content type are the IPMS
contents generated by IPM UAs or the MM contents generated by
MM-UAs. Military Messages 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 element of service enables the MTS to
indicate to a recipient UA that the MTS performed conversion on
the encoded information type(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)
may carry the converted indication. If this indication is present on a
message, it must be displayed to the user. (See X.400 B.15)
d. Delivery time stamp indication This element of service indicates
to the recipient UA, 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 must be displayed to the user.
(See X.400 B.22)
e. MM-message identification (IP-message Identification) This
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
protocol element IPMIdentifier, which carries this service in IPMS,
is replaced by MMIdentifier, which provides structure to the
IPMIdentifier. The MMIdentifier 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 must always be present and must be
displayed to the user. (See X.400 B.37, Annex A B.37)
201. (Continued)
f. Message identification A unique identifier provided 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 elements of service such as
delivery and non-delivery notification. This identifier will be used
internally within the MMHS system. Unlike the MM-message
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)
g. Non-delivery notification This element of service enables the
MTS to notify an originating UA 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 element of service
enables the originating UA to indicate both to the MTS and the
recipient UA the encoded information types (EIT) 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 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 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 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 encoded information type(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. (See X.400 B.93,
Annex A B.93)
202. Optional Elements of Service
The Optional Elements of Service are selected on a per-message
basis. 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 must be implemented,
however, it will only be selected for a given message 202.
(Continued)
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 element of service enables an
originating UA to specify that the message being submitted can be
delivered to an alternate recipient. Alternate delivery takes place if
at least the minimum set of O/R Address attributes required by the
destination Management Domain (MD) are supplied, however, the
entire O/R Address does not match that of a specific UA. This
service works in conjunction with the Alternate Recipient
Assignment EoS. If the destination MD supports Alternate
Recipient Assignment, and a UA has been assigned to receive such
messages, the message will be delivered to the alternate recipient
along with the O/R Address of the intended recipient. The ability to
implement this service is dependent on security procedures in
place. For instance, if the message is encrypted, an alternate
recipient might not have the appropriate key to read the message.
Unless an Originator specifically requests that an alternate recipient
not be allowed, all MMHS messages will indicate that an alternate
recipient is allowed. User interface support for requesting selection
or deselection of this service is required. (See X.400 B.3)
b. Alternate recipient assignment This 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 O/R
Address attributes specified and the O/R Address of the user. Such
a UA is specified in terms of one or more O/R 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
O/R 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
security issues related to the Alternate Recipient Allowed EoS
above. 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 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 O/R
Descriptor of the release authority for the message for information
only. Support for this service is optional. If this service is present,
it can be displayed by the recipient. (See X.400 B.5)
d. Auto-forwarded indication This 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. However, if the indication is present, the
recipient must be able to display it. (See X.400 B.6)
e. Blind copy recipient indication This element of service enables
the originator to provide the O/R Descriptor of one or more
additional intended recipients of the message being sent. These
names are not disclosed to the primary and copy recipients. This
service will be optional for MMHS. 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 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). If
the recipient is a blind copy recipient, an indication must be
prominently displayed to the user. (See X.400 B.8)
f. Body part encryption indication This 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
202.f. (Continued)
encrypting and decrypting that body part are outside the scope of
X.400. 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 will be displayed by the recipient. (See
X.400 B.9)
g. Conversion prohibition This 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. 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
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. See security issue discussed in
2.II.202.g. This service shall be supported as a user option when the
ability to request Explicit Conversion is also supported. (See
X.400 B.14)
i. Cross-referencing indication This 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. Support for this service shall
be optional. If present, this indication must 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)
j. Deferred delivery This 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. A message originator may only request Deferred Delivery
when the precedence of the message is either ROUTINE or
DEFERRED. (See 2.II.207.a for definition of precedence.)
Exceptions can be made when this EoS is used in conjunction with
exercise messages identified with the Message Type EoS. (See
2.II.207.c) When this service is requested, it must be logged for
audit and tracing purposes. (See X.400 B.19)
k. Deferred delivery cancellation This 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 must be supported.
(See X.400 B.20)
l. Delivery notification This 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 202.l. (Continued)
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
can be selected 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. 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 element of
service enables an originating UA to use a directory name in place
of an individual recipient's O/R Address. This implies support of a
Directory. The directory name must be translated to an O/R
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 O/R 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 by 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 a
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)
n. Disclosure of other recipients This element of service enables the
originating UA to instruct the MTS to disclose the O/R Names of
all other recipients of a multi-recipient message to each recipient
UA, upon delivery of the message. The O/R 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 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 the user shall have the
capability to display it. (See X.400 B.26)
p. DL expansion prohibited This 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 a
user option. (See X.400 B.27)
q. Expiry date indication This 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 must be displayed to the recipient(s) to
indicate 202.q. (Continued)
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. (See X.400 B.29)
r. Explicit conversion This element of service enables an
originating UA to request that the MTS perform a specified body
part 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-message indication (Forwarded IP-message
Indication) This 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 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. A military message may
contain both Forwarded-MM and Forwarded-IP messages. (See
X.400 B.31)
t. Grade of delivery selection This 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. (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 will 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 element of service enables a recipient UA
to request that the MTS hold its messages and returning
notifications for 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:
- encoded information type,
- 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 element of service allows an
originator to indicate that this message is an incomplete copy of a
message with the same MM-identifier in that one or more body
parts or heading fields of the original message are absent. This
service might be useful in limited bandwidth 202.v. (Continued)
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 determination of which fields can be left out,
needs to be clarified by national or local policy. This service is
optional. If this indication is present, it shall be displayed to the
user. (See X.400 B.36)
w. Language indication This element of service enables an
originating UA to indicate the language type(s) of a submitted
message. This service shall be optional. If this indication is present,
it shall be displayed to the user. (See X.400 B.38)
x. Latest delivery designation This 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. This service shall be supported as a user option.
(See X.400 B.39)
y. Multi-destination delivery This 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 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)
aa. Non-receipt notification request indication This 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 must 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 must also support
generation of NRNs. (See X.400 B.48)
ab. Obsoleting indication This 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. This
service is optional. If this indication is present it must be displayed
to the user. (See X.400 B.52)
ac. Originator indication The intent of this 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 O/R 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. 202.ac. (Continued)
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 must be
displayed to the user. (See X.400 B.55)
ad. Originator requested alternate recipient This 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 must be displayed to the user. (See X.400 B.56)
ae. Prevention of non-delivery notification This 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)
af. Primary and copy recipients indication This 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
must 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 must 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 element of service
allows the originator to ask, on a per-recipient basis, for
notification when the message being sent is received. The X.400
Recommendations allow 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 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 must 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 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 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 202.ah. (Continued)
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 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. This is a Message Transfer (MT) element of
service. 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)
aj. Reply request indication This element of service allows the
originator to request 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. When a Reply Request Indication is received, the
corresponding Reply message indicates the original message has
been both received and understood. This service shall be supported
as a user option. When this indication is present, it must be
prominently displayed to the user. Additionally, if the supporting
protocol elements reply-time and reply-recipients are present, they
must also be displayed. (See X.400 B.72, Annex A B.72)
ak. Replying MM indication (Replying IP-message Indication) This
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.
The protocol element supporting this service has been renamed
replied-to-MM, which is the same field using an MM-identifier,
rather than an IP-message identifier, to indicate the message to
which this one is a reply in the MMHS context. 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 must be displayed to the user. (See X.400 B.73)
al. Requested delivery method This 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 for optional. (See X.400 B.76)
am. Subject indication This 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 must 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 element of service enables an
originating UA to specify 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 202.an. (Continued)
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 extension service. (See
X.400 B.92)
203. Optional IPMS Elements of Service not used in MMHS
In order to provide a complete comparison of what is available in
Interpersonal Messaging (IPMS) with what will be used in MMHS,
those optional EoS that have been identified as out of scope for
military messaging are listed here. Support for the protocol
elements to support these services are out of scope for military
messaging. 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 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 encoded
information type of one or more body parts of the message to
another encoded information type. 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 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 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. (See X.400 B.35)
c. Probe This 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 encoded information types 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. However, because probes are valid within
the P1 protocol supported by the MTAs making up the MTS for
MMHS, if one is detected it should be logged and either ignored or
a Non-Delivery Notification returned in response. This is an issue
that must be addressed in relationship to gateways to the MMHS.
(See X.400 B.63)
d. Restricted delivery This 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 the CCITT X.400
Recommendations. (See X.400 B.77)
e. Return of content This 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)
f. Sensitivity indication This element of service allows the
originator of a message to specify guidelines for the relative
sensitivity of the message upon its receipt. It is a local matter
whether the sensitivity is displayed to the user or interpreted by the
system. 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 might conflict with the Message
Security Label, which conveys more information. (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 Elements of Services
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 for the protocol elements in P1 to carry the X.400 Security
Elements of Service are conditional on national security policy. A
discussion of Security requirements in the MMHS context can be
found in 4.II.
206. Message Store Elements of Service
The Message Store EoS are associated with the use of an X.400
Message Store (MS). Support for the MS Elements of Service are
dependent on use of an MS and do not impact interoperability with
configurations without an MS. Further discussion of the use of
Message Stores will be found in 3.II.305, 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. Support for this EoS is optional. (See X.400 B.4n)
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 with an MS can
receive time critical messages, the associated MS shall support this
service. (See X.400 B.82)
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 with an MS may be
unavailable for a period of time, 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
available, this service is mandatory. (See X.400 B.84)
206.d. (Continued)
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 available, 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 available, 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 available this service is mandatory.
(See X.400 B.87)
SECTION II
ADDITIONAL MILITARY ELEMENTS OF SERVICE
a. The additional Military Elements of Service provide services
required within the MMHS context that are not found in the
civilian X.400 Recommendations. 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 must
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 content 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 Delivery.
This service is supported by the military heading extension
primaryPrecedence. (See page A-30) The six 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 NON-URGENT
ROUTINE NON-URGENT
PRIORITY NORMAL
IMMEDIATE NORMAL
FLASH URGENT
OVERRIDE 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 must be displayed to the recipient. (See Annex A
B.101) The Primary Precedence level must be prominently
displayed for each Primary recipient user.
b. Copy Precedence This element of service enables an originating
MM-UA to convey the additional precedence of a message in the
content 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 207.b. (Continued)
must 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 must be displayed to
the user. (See Annex A B.102) This service is supported by the
military heading extension copyPrecedence. (See page A-30) The
Copy Precedence level must 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 messageType. This service is a user
option. If present, the Message Type EoS must be prominently
displayed to the user. (See page A-30)
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 AddressListIndicator 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. The names or
addresses of exempted list members is also conveyed to the
remaining recipients and must be displayed to the user. There is no
guarantee that the exempted addresses will not receive the message
as the result of redirection, DL explansion, etc. (See Annex A
B.105) This service is carried by the military heading extension
exemptedAddress. (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 extendedAuthorisationInfo. This
information shall be present on all officially released military
messages, and shall be displayed to the user on reception. (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 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. 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 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 distributionCodes. This information is a user option on
origination, but must 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. This information, if present, must 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 messageInstructions. (See page A-29)
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
207.h. (Continued)
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.
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 AddressListIndicator 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 otherRecipientsIndicator and if present, must 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 MM-identifier in that this reference is assigned by the
originator, while the MM-identifier 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 originatorReference. (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. Expansion of the AL to the members of the list for use in
the MTS is the responsibility of the domain of the originating MM-
UA. Expansion entails placing the necessary address information
for each 207.k. (Continued)
member of the list in the P1 envelope. The MM content heading
will indicate the AL rather than the member names. 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 addressListIndicator. (See page A-30) Use of the
AddressListIndicator 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 addressListIndicator 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 must be displayed to the user.
208. Transition Elements of Service
The following Military Elements of Service 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 handlingInstructions. (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
pilotForwardingInfo. (See page A-31) This information, if present,
must 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 acp127MessageIdentifier heading field. If this information is
present, the user shall be able to display it. (See page A-31)
208.d. (Continued)
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 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 originatorPlad. (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 codressMessage 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
codressMessage. (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 acp127NotificationRequest
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
acp127NotificationResponse 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.
CHAPTER 3
MESSAGE HANDLING SYSTEM COMPONENTS
SECTION I
Message Transfer System
a. In the X.400 Message Handling Environment, messages are
relayed in a store-and-forward fashion between Message Transfer
Agents (MTAs) until the message reaches the specified
destination(s). The collection of MTAs (and the underlying
communication service) is referred to as the Message Transfer
System (MTS). Since it has been agreed that there may be a
requirement to use a commercially provided MTS service,
modifications to the existing Message 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 a specific profiles for use
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. Submission Control to prohibit use 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
will be the responsibility of gateways to prohibit probes that
originate outside the MMHS environment from entering an MMHS
domain.
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.
SECTION II
Military Messaging (MM) User Agents
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 Military Messaging User Agents (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 message stores or
intermediate storage between the MTA and a remote UA.
305. Storage and retrieval policies How long messages must 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.
SECTION III
Message Stores
a. A Message Store (MS) is designed to support off-line storage of
messages when the intended recipient's UA is unavailable to accept
messages from the MTS. MS is an optional component and its use
with any given MM-UA will be determined by national or local
policy. 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, including:
315. High precedence messages and message alarms If an MS is
used with an MM-UA, it must support Stored Message Alert EoS
(See 2.II.206.a) to ensure that an operator is alerted when high
precedence messages, as signaled by URGENT priority in the
delivery envelope, are delivered.
316. High precedence messages and autoforward If an MM-UA
with a MS will be unmanned for a period of time and may receive
high precedence messages, the MS must either support
autoforwarding or support the ability to establish redirection of
incoming messages by the MTS. The ability to do either auto-
forwarding or redirection may be affected by security policies.
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 Military Messages 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.
403. Precedence Handling (local) - The extension fields
primaryPrecedence and copyPrecedence 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.
(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.
403.a. (Continued)
(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. Signaling - The precedence values must be prominently
displayed to the recipient with the message. Additionally, messages
with precedences that map to the URGENT Grade of Delivery must
cause the MM-UA to prominently (e.g., audibly) signal the
recipient upon delivery. (See 2.II.207.a)
c. Grade of Delivery - The primaryPrecedence 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 two copies of the MPDU will be sent from 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.
d. 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.
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. This 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 that 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:
404. (Continued)
- 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 must 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 must
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.
- 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).
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 407. (Continued)
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 must 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 - If a received message
fails the security checks for content integrity, as much of the
heading information as could be successfully decoded or decrypted
will be displayed to the recipient, with an indication that the
security content integrity check failed. It will then be the recipient's
responsibility to contact the originator and request retransmission
of the message. If it is necessary to verify that all or part of a
message is valid, a separate message will 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. Further, 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. Records - Records will be kept at each MM-UA recording
information regarding messages sent and received to provide an
audit capability. The requirements for exactly what information is
kept and for how long is a national matter. However, the minimum
information that should be logged for both incoming and outbound
messages include:
the unique MM Identifier,
the Message Identifier,
Precedences assigned,
Security Labels, and
the Extended Authorization Information.
Outbound messages should also log:
requested recipients,
the Submission Time,
if Deferred Delivery was requested, the Deferred Delivery Time,
Notifications requested (including if Prevention of NonDelivery
Notifications was requested), and
the Release Authority.
Incoming messages should also log:
the originator, and
the Delivery Time.
MTAs will also maintain logs. At a minimum each MTA should log
the following for each message:
the message identifier,
time of receipt, and
time of transfer.
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.
411. Tracer Action - If acknowledgment of a message is requested
and not received by an originator, then the user can request a Tracer
Action. This can take the form of sending a new message to the
same recipient to see if it gets delivered. Alternately, a Tracer
Action may consist of a request for operator assistance in
examining whatever audit trail records are available. The method by
which audit logs can be traced is a management issue that should
be addressed by national policy. However, if an MMHS domain can
show from its audit logs 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
must state exactly what is meant and must 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.
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 must also be present in all messages
conveying non-text body parts. Every body part included must
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. A Military Message 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
transmission speed requirements for the underlying transmission
backbone (i.e., the X.400 MTS). The second aspect is the speed of
local handling of messages received by recipient UAs and users.
Both of these aspects are tied to the precedence levels associated
with the message. The following table shows the overall speed of
service requirements as a function of precedence levels and the
corresponding Grade of Delivery selection. The maximum message
size, shown in the table, is not intended to constrain the size of
messages that the system will be able to carry at each precedence
level. However, these message sizes represent the maximum for
which the required speed of service must 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.
413. (Continued)
PrecedenceMTS Grade of Delivery MTS Time of
DeliveryOriginator-to-Recipient Time of Delivery Max. Message
Length (in Characters) OVERRIDE, FLASHURGENT (2) As fast
as possible, no more than 3 minutes 3 minutes
10 minutes
5,400
7,000
IMMEDIATE, PRIORITYNORMAL (0) No more than 20
minutes20 minutes
45 minutes
1,000,000
2,000,000
ROUTINE, DEFERREDNON-URGENT (1) No more than 8
hours, or start of next business day No more than 8 hours, or start
of next business day 2,000,000
a. Speed of Transmission
In order for the precedence level to affect the speed of message
transit through the MTS, the precedence level will be mapped to
the Grade of Delivery Selection upon submission. If the
transmission speed required of the MTS cannot be met, the MTS
shall continue trying to deliver the message as quickly as possible.
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. For messages with a maximum precedence
of ROUTINE, ninety-six hours (four days) is the recommended
time at which a message is deemed undeliverable. This
recommendation was determined by calculating the maximum
amount of time until the start of the next business day. The
calculation considers the possibility of a three day weekend and the
possibility that the originator and recipient are in maximally
divergent time zones. 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 MM-Identifier or other
heading field in the second message is different, 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
MM-Identifier, 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 MM-Identifier 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 MM-Identifier.)
415. Conversion - Conversion is not compatible with integrity,
authentication, and content confidentiality. Implicit Conversion
should not be used in the military environment. If conversion is
415. (Continued)
required it should be done by Explicit Conversion and only when
originator to recipient security services are not required.
416. References
a. When references are made to other messages that have been
conveyed as MM, the MMIdentifer 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).
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 MMIdentifiers, 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. Exercise Communications
a. Exercise messages
Messages sent during and relating to training exercises, command
post exercises, tactical exercises and maneuvers conducted in the
interest of training and readiness are exercise messages but are
prepared and handled in the same way as normal traffic.
b. Identification of Exercise Message:
(1) Exercise messages are identified using the protocol to support
the Message Type EoS. They use the exercise value (0) for the type
and the name or designation assigned by a proper authority in the
identifier of the messageType protocol element of the message
heading.
(2) The organization conducting the exercise shall include
appropriate instructions for identifying exercise messages in the
directive for the conduct of the exercise in order to preclude
alarming non-participants. Normally these instructions will require
that the exercise identification be included with the message by
including the optional messageType protocol element of the
message heading.
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.
420. Message confidentiality - This service protects against
unauthorized disclosure of the message.
421. 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.
422. Data origin authentication - This service provides assurance
that the message was originated by the user indicated as the sender.
423. 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 must not violate the security policies of the originators and
recipients.
424. Message Non-repudiation with proof of origin - This service
provides the recipient of a message with proof of the origin of the
message. This provides the ability to demonstrate 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.
425. Message Non-repudiation with proof of delivery - This service
provides the originator of a message with proof of the delivery of
the message. This provides the ability to demonstrate 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.
426. 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 must also indicate the Security Policy to
be followed.
427. Accountability - This service provides assurance that messages
sent are received by the intended recipient, or the originator is
notified if there were any problems with delivery.
428. Prohibition of Probes - This service prohibits users from
finding out information about potential recipients on the network
without the knowledge of the recipient. This service may have to be
implemented by the gateways into ACP 123 MHS domains not
letting probes pass the gateway.
429. 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 429.
(Continued)
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
security classification of a message must 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.
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.
Acceptable security labels and the policies associated with them are
defined by national policy or multi-national agreement outside the
body of ACP 123.
SECTION III
NAMING AND ADDRESSING
a. Users of MMHS are identified by O/R Names, which consist of
either an O/R Address, a Directory Name, or both. The O/R
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 O/R 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 O/R 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 O/R Address
serves to name originators or recipients. Therefore, the distinction
between Naming and Addressing is not always entirely clear.
435. O/R Addresses
a. The Mnemonic, Terminal, and Numeric forms of O/R address (as
defined by X.402) shall be supported by all MM-UA and MM-MS
elements. The address support requirements for MTAs are
addressed by ISO/IEC ISP 10611.
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 are defined to be used
in interworking with the ACP 127 domain. Support for generating
and displaying these DDAs when part of an O/R Address is
mandatory. The use of these DDAs is optional when defining the
O/R Address of any given user. If ACP 127 users are not registered
in the MMHS, then those users will be identified by the O/R
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
435. (continued)
d. The Domain Defined Attributes will not be used for inter-
domain routing purposes.
436. 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 O/R addresses. In order for messages to
be delivered via the MTS, the correct O/R 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 O/R addresses are present. The originating domain may use
the directory name to look up a corresponding O/R address for use
on the message envelope. Successive domains in the delivery path
are required only to relay the directory name field for possible use
by the recipient MM-UAs.
437. Address Lists
This section addresses the unique requirements involved with
short-hand methods of addressing lists of recipients. An Address
List (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
O/R Names in the primary-recipients or copy-recipients fields, or in
the AddressListIndicator field. (See 2.II.208.f)
a. List Expansion
The originating domain is responsible for expansion of the list,
including responsibility for any associated exempted addresses.
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.
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.
437. (continued)
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.
438. 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 military messaging system. The Directory will support
a number of critical functions that will be used to support
everything from O/R 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. One
method for this would be use of a common directory service.
SECTION IV
MANAGEMENT
a. Military Messaging in MMHS will be possible by the
interconnection of MMHS management domains 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.
440. Accounting policies and procedures
Bilateral agreements may need to be arranged to support
requirements for accounting policies and procedures across
national boundaries.
441. Trace and Accountability
Requirements for the minimum information to be logged at MM-
UAs and MTAs are specified under procedures for records. (See
4.I.410) This information will be used to provide accountability
and support for any required Tracer actions. The required time for
retention of these logs will be a national matter. Bilateral
agreements may be necessary to coordinate tracer action across
national boundaries. The interface points will maintain the
information necessary to support message tracing/accountability
from one domain to another.
442. 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.
443. 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 Military
Messaging 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 elements of
service must be supported, an implementation cannot claim
conformance to the specified profile without implementing those
optional elements of service.
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
Standard Profile
501. Profile Definition
a. This MMHS Standard Profile specifies any additional required
behavior of Messaging 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. 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.
502. Additional requirements on Elements of Service
The following EoS shall be supported as user options.
a. Authorizing users indication
b. Cross-Referencing indication
c. Designation of recipient by directory name
d. Incomplete copy indication
e. Language indication
f. Obsoleting indication
SECTION II
Restricted Profile
505. Profile Definition
a. This MMHS Restricted Profile is being developed in response to
the concern that standard X.400 messaging will not operate
efficiently in networks where transmissions are constrained by
simplex operation, low link speed, brief on-the-air time, high error
rates, etc. This profile reduces the amount of overhead using a
variety of techniques, yet maintains interoperability with the
standard profile. The required characteristics of MMHS as
specified in Chapters 2 and 4 of this document apply as the base
requirements for Military Messaging. There may be some restricted
environments where even this limited X.400 profile may place too
much strain on available resources in which case the MMHS
requirements may stop at a gateway to this restricted environment
where military messaging is handled in some other fashion, the
scope of ACP 123 stops at the ACP 123 side of that gateway. This
section provides an informative description of the likely makeup of
the Restricted Profile.
506. Profile Components
The Restricted Profile will adapt the ACP 123 EoS and procedures
to the restricted communications environment by use of the
following techniques:
1. Adoption of connectionless communication protocols
2. Use of presentation-layer compression
3. Selection of more efficient encoding rules
4. Use of more efficient addressing schemes.
a. Connectionless Communications
While the X.400 architecture is broadly applicable to a wide range
of communications scenarios, the protocols defined to support the
Message Transfer Service Element (MTSE) and other Application
Service Elements (ASEs) are designed to operate effectively only
over a relatively responsive, connection oriented network. In order
for X.400 services to be adequately conveyed across simplex,
broadcast communication stacks, it is necessary to modify the
X.400 protocol stack to operate in a connectionless mode.
Specification of the exact makeup of such a stack will be an
inherent part of the restricted profile.
b. Presentation-Layer Compression
The Restricted Profile will allow the use of one or more
compression algorithms that can compress all or part of the
application layer data. There are currently proposed modifications
to the Presentation Layer Service Definition (ISO 8822) and
Protocol Specification (ISO 8823) to incorporate this feature in the
protocols. The algorithm used, if any, would be negotiated during
connection setup. Since different algorithms could be used between
different MTAs, there is no need for the sender or recipient of a
message to use the same algorithm or even be aware of which
algorithm the other is using. Further specification of the use of
these techniques will be left for further study as the proposed
modifications are stabilized within the Presentation Layer
Specifications. This may actually be outside the scope of ACP 123
which is concerned only with the Application Layer specification
of military messaging, however it must be considered in meeting the
requirements for this restricted bandwidth profile.
506. (continued)
c. Encoding Rules
Encoding Rules specify how data fields are mapped into bit
representations for transmission between application entities.
Currently there is only one set of internationally standardized rules,
referred to as the Basic Encoding Rules (BER) (ISO 8825). Use of
these rules result in relatively large amounts of overhead. More
efficient rules have been proposed which appear to be much more
favorable for a restricted environment since they significantly
reduce the number of bits generated. These are known as Packed
Encoding Rules (PER), and are expected to become a Draft
International Standard in the summer of 1993. The restricted profile
may mandate support of both PER and BER. PER will be used
whenever possible, however since both the standard and restricted
profiles will support BER there should not be an impact on
interoperability. The Presentation Layer already allows for
negotiation of which rules will be used during connection setup.
The encoding may vary between MTAs so the sender and recipient
of a message do not need to be using the same rules or be aware of
which rules the other is using. Further specification of the use of
these techniques will be left for further study as the proposed
encoding rules stabilize within the international standards process.
d. Addressing
The mnemonic address format is most commonly used with X.400
and is the format used most often within the Standard Profile for
MMHS, however it is also the lengthiest format. Since addresses
contribute substantially to X.400 overhead, reduction of address
length may help reduce overhead considerably. The restricted
profile will use numeric addresses for users within the restricted
environment. Mnemonic addressees must still be able to be
interpreted and received in order to maintain interoperability with
users of the standard profile.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
