|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
DoD Required Operational Messaging Characteristics
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.
Required Operational Messaging Characteristics (ROMC)
TABLE OF CONTENTS (TOC)
SECTION 1 - INTRODUCTION 1
1.1 PURPOSE 1
1.2 APPLICABILITY 1
1.3 APPROACH 2
1.4 DESIGN CONSIDERATIONS 4
1.5 ORGANIZATION 5
SECTION 2 - DMS MESSAGING REQUIREMENTS 6
2.1 INTRODUCTION 6
2.2 MROC GENERAL CHARACTERISTICS 6
2.3 MROC REQUIREMENTS/MESSAGING CHARACTERISTICS 7
2.3.1 CONNECTIVITY/INTEROPERABILITY 7
2.3.2 GUARANTEED DELIVERY/ACCOUNTABILITY 8
2.3.3 TIMELY DELIVERY 10
2.3.4 CONFIDENTIALITY/SECURITY 12
2.3.5 SENDER AUTHENTICATION 13
2.3.6 INTEGRITY 14
2.3.7 SURVIVABILITY 15
2.3.8 AVAILABILITY/RELIABILITY 15
2.3.9 EASE OF USE 16
2.3.10 IDENTIFICATION OF RECIPIENTS 17
2.3.11 MESSAGE PREPARATION SUPPORT 18
2.3.12 STORAGE AND RETRIEVAL SUPPORT 19
2.3.13 DISTRIBUTION DETERMINATION AND DELIVERY 20
APPENDIX A - DEFINITION OF TERMS A - 1
APPENDIX B - ABBREVIATIONS B - 1
APPENDIX C - LIST OF REFERENCES C - 1
SECTION 1 - INTRODUCTION
(TOC)1.1 PURPOSE
This document presents a compilation of writer-to-reader system
requirements for both organizational and individual messaging
within the Defense Message System (DMS). These requirements,
referred to as the DMS Required Operational Messaging
Characteristics (ROMC), are based on the 13 general DMS messaging
requirements outlined in Section I of the Joint Staff validated
Multicommand Required Operational Capability (MROC) 3-88,
implemented 6 February 1989.
The MROC requirements were written from a high-level point of
view and are neither specific in nature nor quantified/qualified
to any degree. The ROMC has been developed to refine the MROC
requirements into more specific, detailed and, wherever possible,
quantitative/qualitative requirement statements. These
requirement statements are referred to as characteristics.
(TOC)1.2 APPLICABILITY
The DMS ROMC is applicable to all Department of Defense (DOD)
Services and agencies that specify, develop, implement, and
acquire DMS components. The DMS consists of all hardware,
software, procedures, standards, facilities, and personnel used
to exchange messages electronically between organizations and
individuals in the DOD. The DMS baseline architecture consists
of the Automatic Digital Network (AUTODIN), to include base-level
support systems, and electronic mail exchanged on the DOD
Internet. Although the characteristics specified herein remain
implementation independent, the DMS baseline has been studied to
determine generic messaging requirements specified in this
document.
The characteristics listed within this document should be
considered in total when evaluating message system designs or
implementations. Many of the characteristics are interdependent
and will provide the necessary assurances only when applied in
combination with one another. Additionally, a number of the
characteristics are attributable to more than one of the 13
general MROC requirements, but, in the interest of brevity, were
not repeated within this document.
(TOC)1.3 APPROACH
The ROMC is directly traceable to the MROC. It provides
additional detail about the 13 general MROC requirements. It
also incorporates characteristics derived from the DMS baseline,
which have been mapped to one or more of the MROC requirements.
The ROMC is specified and quantified from a writer-to-reader
point of view. It is also solution independent and does not
assume any specific implementation approach. In many cases, the
specific quantitative characteristics are derived from the DMS
baseline requirements. In other cases, quantitative
characteristics have been developed through best engineering
estimates, based on comparable or state-of-the-art systems having
similar requirements. In all cases, the characteristics have
been evaluated from the writer-to-reader viewpoint to ensure that
all quantified parameters are properly applied. In cases where
quantitative parameters are not applicable or cannot be derived
from the DMS baseline, characteristics are expressed in
qualitative terms. In a number of instances, the characteristics
are expressed by using a combination of quantitative and
qualitative parameters.
The validated DMS ROMC is an extension of the requirements
contained in DMS MROC 3-88. As depicted in Figure 1, the ROMC
serves as the requirements basis for all DMS projects and
components in the following manner.
The quantitative and qualitative detail contained in the ROMC is
used to refine and add detail to programmatic support documents
that facilitate transition to the DMS Target Architecture. The
primary DMS programmatic support document is the Target
Architecture and Implementation Strategy (TAIS). The ROMC is
used as the requirements basis for continual refinement of
detailed transitional architectures contained in the TAIS
appendices in defining required DMS projects and components. The
ROMC also serves as the basis for (1) test and evaluation
criteria contained in the DMS Test and Evaluation Master Plan
(TEMP), (2) the DMS Logistics/Operational Support Guidance
document, and (3) the DMS Component Approval Process (CAP). The
ROMC, with these programmatic support documents, serves as the
basis for defining specific requirements for each DMS project and
all resulting components.
(TOC)1.4 DESIGN CONSIDERATIONS
In evaluating messaging requirements, it is important to realize
that certain procedures and/or mechanisms must be considered to
ensure specific implementations are designed in a manner
consistent with those requirements. Although every component of a
messaging system may be designed with different considerations,
the following are some of those design factors derived from an
evaluation of the MROC requirements, as well as the DMS baseline.
It is imperative that all systems developed in support of the DMS
include each of these consideration in the planning phase of the
development.
a. The message audit trail should provide information to
support fault isolation, as well as performance and security
monitoring.
b. No single hardware, software, and/or human error
malfunction should allow security checks to be bypassed.
c. The system should incorporate self-test and diagnostic
features, as well as supporting maintenance documentation.
d. All software and hardware should be designed and
implemented in accordance with applicable Government, military,
or commercial standards.
e. All hardware and software should be modular to
facilitate the ability to add, remove, replace, or modify with
little or no impact to operations and/or security.
f. System administrators should have access to the
following set of auditable features:
(1) Configuration monitoring and control
(2) Status monitoring and performance assessment
(3) Fault isolation and correction
(4) System component internal control information
g. Protection against message looping and message
shuttling within the system should be provided.
(TOC)1.5 ORGANIZATION
a. This document has two sections. Section 1 explains the
purpose and applicability of this document, as well as outlining
the approach taken to produce the characteristics listed in
Section 2. This section also contains a listing of items to be
considered when implementing a messaging system.
b. Section 2 presents both the general requirements as
stated in MROC 3-88, as well as the more specific messaging
characteristics attributed to those requirements. This is the
heart of the document and forms the basic structure of the ROMC.
c. Appendix A provides definitions of messaging terms and
phrases used throughout the document. All definitions contained
in Appendix A are relevant only in the context of this document.
Those terms and phrases defined in the appendix will be
underlined in section 1.4 and section 2 of the document, where
the applicability to specific characteristics is most critical.
d. Appendix B presents a list of all acronyms used
throughout the document.
e. Appendix C provides a list of references used to
research and compile the characteristics contained in Section 2.
SECTION 2 - DMS MESSAGING REQUIREMENTS SECTION
(TOC)2.1 INTRODUCTION
For each of the fundamental DMS requirements outlined in MROC
3-88, further specified operational messaging characteristics are
necessary for organizational and/or individual messaging. These
characteristics are listed in the following sections. Each
section first includes the fundamental requirement, verbatim, as
stated in the Joint Staff validated MROC 3-88. This is followed
by those messaging characteristics attributed to that MROC
requirement.
Following each characteristic, an indication is included which
signifies that the characteristic is either an organizational
messaging characteristic, shown as (org), an individual messaging
characteristic, shown as (ind), or both, shown as (org/ind).
Selected individual messaging users may be authorized to
originate high precedence or classified traffic. Although not
organizational, these messages must be afforded the same
guarantees applied to high precedence or classified
organizational messages. These individuals include those who,
although originating/receiving individual messages, speak for,
represent at a high grade level, and/or are necessarily
identified with their respective organizations.
Where not specifically disallowed, and where there is no stated
individual messaging counterpart to a characteristic indicated as
(org), implementors may impose comparable characteristics for
individual messaging. Additionally, these characteristics
represent minimum essential requirements and, unless specifically
disallowed, local implementors may impose more stringent
parameters to meet specific needs.
(TOC)2.2 MROC GENERAL CHARACTERISTICS These general characteristics,
included from Section I, paragraph 1.a. of MROC 3-88, have been
separated into independent paragraphs for greater clarity.
a. The DMS shall provide (1) message service to all DOD
users, to include tactical users, (2) access to and from
worldwide DOD locations, and (3) interface to other U.S.
Government and allied users , as well as defense contractor and
other authorized users (e.g., academia) as needed. To minimize
delay, this service shall be direct to the end user whenever
possible (org/ind).
b. The DMS shall reliably handle information of all
classification/sensitivity levels (unclassified to TOP SECRET),
compartments, and handling instructions (org/ind).
c. In addition to maintaining high reliability and
vailability, the DMS must interoperate with current message
systems as they evolve from the baseline to the target
architecture (org/ind).
d. The DMS shall be a vehicle for planned growth and
technology enhancements that do not exist today(org/ind).
e. The DMS shall be based upon the principles of
standardization and interoperability, while preserving
adaptability to implement Service and agency unique functions
(org/ind).
f. The major elements of the current collection of
subsystems upon which the DMS will be built include the AUTODIN
system (including base-level support systems) and the electronic
mail systems on the DOD Internet (principally within the Defense
Data Network (DDN) and associated local area networks
(LANs))(org/ind).
(TOC)2.3 MROC REQUIREMENTS
The stated MROC requirements in the following sections have been
included from MROC 3-88, Section I, paragraph 1.a(1)(a) through
1.a(1)(m), as written. In order to maintain continuity these
MROC requirements have not been altered. Further specification
is contained in the characteristics following each MROC
requirement.
(TOC)2.3.1 CONNECTIVITY/INTEROPERABILITY
A. MROC Requirement. The DMS should allow a user to
communicate with any other user within the DMS community. The
community of users includes organizations and personnel of the
Department of Defense to include deployed tactical users. In
addition, the DMS must support interfaces to systems of other
Government agencies, allies, tactical, and Defense contractors.
System users may be fixed, mobile, or transportable.
Connectivity must extend from writer to reader. Messages
should be composed, accepted for delivery, and delivered as
close to the user as is practical. Current efforts, such as
extension of automation to users and improved base level
message distribution systems, are responsive to this
requirement.
The DMS must be interoperable with tactical data
distribution systems. The DMS must also be interoperable
with and provide standard interfaces for allied systems. It
should lead DOD's migration to international standards and
protocols.
B. Characteristics.
1) Provide standard interfaces to other
Government agencies, allies, defense contractors, and other
approved activities external to the DMS community (org/ind).
2) Provide full support to tactical users
(org/ind).
3) Allow for minimum required message syntax
changes to accommodate differences in capabilities between
component systems serving the message originator and the intended
recipient, unless explicitly prohibited by the message originator
(org/ind).
4) Interoperability between user communities
will be restricted to interfaces utilizing authorized and
approved mechanisms (e.g., components, procedures, protocols).
User communities are differentiated by discriminators such as
security considerations, message types, high/low bandwidth
communications, etc.. (org/ind).
(TOC) 2.3.2 GUARANTEED DELIVERY/ACCOUNTABILITY
A. MROC Requirement. The DMS must, with a high
degree of certainty, deliver a message to the intended
recipient(s). If the system cannot deliver a message, a method of
promptly notifying the sender of the non-delivery must be
available. For organizational message traffic, the DMS must have
the capability to maintain writer-to-reader message
accountability.
B. Characteristics.
1) Guarantee delivery to the intended
recipient(s) with a probability of greater than:
- 99.99 percent (org)
- 99.00 percent (ind)
Note: Messages not delivered to the intended
recipient(s) include both detected and undetected
non-deliveries.
2) Probability of undetected message loss must
be less than one message out of 100 million (org/ind).
3) The writer must retain the capability to
re-submit the entire message until acknowledgement of message
delivery. The system shall provide the writer with the
following:
a) Sender delivery notification of message
by globally unique message identifier (org/ind)
b) Sender non-delivery notification of
message by globally unique message identifier (org/ind)
c) Non-repudiation of message receipt
(org/ind)
4) Provide guarantees that if any message is
broken into segments the intended recipient will be presented the
message as submitted (org/ind).
5) Provide message accountability and audit
trail for all messages from writer to reader, based on a globally
unique message identifier which supports:
a) Analysis of both security monitoring and
security related events (i.e., successful/unsuccessful log-in
attempts, violation of security policy, release of messages,
etc..) (org/ind)
b) Message traceability from the source
(org)
6) Provide the means to cancel or rescind a
message (org/ind).
(TOC) 2.3.3 TIMELY DELIVERY
A. MROC Requirement. The DMS must recognize
messages that require preferential handling. The urgency of the
most critical information requires handling above and beyond
simple priority. The DMS must dynamically adjust to changing
traffic loads and conditions to provide timely delivery of
critical information during peacetime, crisis, and war. Delivery
time for a given message will be a function of message precedence
and system stress level.
B. Characteristics.
1) The message originator will assign
precedence(s) for each message which reflects the message
importance and thereby determines the required speed of service
for the intended recipient(s) (org).
2) The system will support the following
precedence levels organized into precedence category as follows
(org/ind):
CATEGORY PRECEDENCE
URGENT CRITIC, ECP
Flash
IMPORTANT Immediate
Priority
NO N-URGENT Routine
3) Individual messages, not originated by
those selected individual messaging users identified in paragraph
2.1, shall be originated as ROUTINE (ind).
4) Messages will be processed, delivered, and
presented to the intended recipient in First-In-First-Out (FIFO)
by category/precedence order (org/ind).
5) Lower precedence message traffic will not
delay higher precedence message traffic (org/ind).
6) Message length is provided for purposes of
establishing throughput and speed of service requirements. These
message lengths do not represent minimum requirements. Certain
portions of the DMS will be required to process messages of a
greater length than that specified. The specific message length
will be dependent upon those users supported by particular
portions of the system and the types of messages which must be
processed by those portions. However, those speed of service
characteristics, listed in (7) below, cannot be guaranteed for
messages exceeding the above stated message lengths.
The DMS shall handle messages of various types,
which may contain human readable textual data, data intended for
display by automated systems (such as imagery data), data
intended for processing by automated systems (such as input to
databases), or any combination of these.
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 (message content only). This overhead must be
considered when implementing components of the system.
The system shall provide the ability to process
a message with the following message lengths (in characters)
within the respective speed of service (org/ind):
PRECEDENCE MESSAGE LENGTH
CRITIC 5,400
ECP 5,400
FLASH 7,000
IMMEDIATE 1,000,000
PRIORITY 2,000,000
ROUTINE 2,000,000
7) Writer-to-reader speed of service for all
messages will be less than (org/ind):
CATEGORY PRECEDENCE SPEED OF SERVICE
URGENT CRITIC (W), ECP (Y) 3 min
Flash (Z) 10 min
IMPORTANT Immediate (O) 20 min
Priority (P) 45 min
NON-URGENT Routine (R) 8 hrs
8) Messages originated at various precedence
levels will be limited on a user by user basis (org/ind).
9) Provide support for changing traffic loads
and conditions in time of peace, crisis, and war, as follows,
such that all messaging characteristics continue to be achieved
(org).
a. Accommodate peak message rates
required in times of crisis (150 percent of the peak peacetime
rate), and war (200 percent of the peak peacetime rate) (org).
b. Accommodate peak traffic volumes
required in times of crisis (175 percent of the peak peacetime
volume), and war (225 percent of the peak peacetime volume)
(org).
10) Uniquely recognize and alert intended
recipients, or designated alternate recipient (if applicable), of
the arrival of each CRITIC, ECP, and Flash message (org/ind).
11) Provide a mechanism which allows message
originators to include a perishability indicator into selected
messages. This indicator will specify the time after which the
message should no longer be delivered or acted upon. A method
for notifying the message originator if the indicated time has
been reached without action shall be implemented (org).
12) Universal Time Coordinated (UTC) will be
the standard time reference for all messages (org/ind).
(TOC) 2.3.4 CONFIDENTIALITY/SECURITY
A. MROC Requirement. Confidentiality precludes
access to, or release of, information to unauthorized users. The
DMS must process and protect all unclassified, classified, and
other sensitive message traffic at all levels and compartments.
The DMS must maintain separation of messages within user
communities to satisfy confidentiality. Security is based upon
requirements for integrity and authentication as well as
confidentiality.
B. Characteristics.
1) Protect all classified and sensitive
information at the appropriate security level and compartment as
specified in appropriate classification regulations and Public
Law 100-235 (org/ind).
2) Provide writer-to-reader message
confidentiality for all unclassified sensitive and classified
messages (org/ind).
3) Continuously maintain the separation of
messages and their included information between user communities,
either physically (i.e., classifications) or through the use of
unambiguous identifiers (i.e., exercise traffic) (org/ind).
4) Support the appropriate message security
classification labels and markings in accordance with DODD
5200.28 and DOD 5200.1R (org/ind).
5) Provide for authentication, access
management, and access control using approved DMS mechanisms
(org/ind).
6) When required, National Security Agency
(NSA) approved cryptographic devices appropriate to the
classification and sensitivity of the message traffic shall be
used in accordance with DODD 5200.28 and DCID No 1/16, and
SM-313-83 (org/ind).
7) Provide for the irrevocable emergency
destruction of stored messages, where necessary and when needed,
to protect unclassified sensitive and classified messages
(org/ind).
8) Provide appropriate security measures
(e.g., physical security, personnel security, INFOSEC, COMSEC,
and COMPUSEC) in accordance with DMS security policy (org/ind).
(TOC) 2.3.5 SENDER AUTHENTICATION
A. MROC Requirement. The DMS must unambiguously
verify that information marked as originating at a given source
did, in fact, originate there. For organizational message
traffic, a message must be approved by competent authority before
transmission.
B. Characteristics.
1) Provide a strong authentication mechanism
for message origin authentication and non-repudiation of origin
(org/ind).
2) An authorized Message Release Authority
must approve all organizational messages before submission (org).
3) Provide the ability to differentiate
between individual and organizational messages at origination and
upon message receipt (org/ind).
(TOC) 2.3.6 INTEGRITY
A. MROC Requirement. Information received must be
the same as information sent. If authorized by the writer, the
DMS may make minimal format changes to accommodate differences in
capabilities between the component systems serving the writer and
the reader. However, the DMS must ensure that information
content of a message is not changed.
B. Characteristics.
1) The message text and data contents received
by an intended recipient must be the same as that sent by the
message originator (org/ind).
2) Except for message syntax changes that are
an integral and authorized part of a particular component, the
system will not cause a message to lose, add, or modify the body
(text or data) of the message (org/ind).
3) Unauthorized combining of messages either
by intermixing or concatenating during submission, validation,
processing, or delivery is prohibited (org/ind).
4) Provide to the message originator, upon
request, and the intended recipient, at all times,
verification that the message content has not been modified
(org/ind).
5) Provide verification procedures (either
automated or manual) to ensure information regarding message
security, precedence, syntax, and addressing is valid (org/ind).
6) Prevent submission of a message with
detected unacceptable errors. The acceptability of an error is
determined by both the system implementation and messaging policy
(org/ind).
7) Notify the intended recipients when
messages are suspected duplicates (org).
8) Provide safeguards against accidental,
unauthorized, or malicious actions that result in the:
a) Alteration of security protection
mechanisms or access levels (org/ind).
b) Alteration of the security
classification levels (org/ind).
c) Alteration/change of addressing or
routing information (org/ind).
d) Alteration of audit information
(org/ind).
(TOC) 2.3.7 SURVIVABILITY
A. MROC Requirement. The DMS must provide a service
as survivable as the users it serves. It must not degrade the
survivability of systems interfaced to it. Methods such as
redundancy, proliferation of system assets, and distributed
processing may be employed. Surviving segments of the DMS must
be capable of reconstitution.
B. Characteristics.
1) Provide for graceful system degradation and
orderly system recovery from failures, in accordance with
applicable restoration priorities (org/ind).
2) Surviving system segments must be capable
of reconstitution as a system to provide essential messaging
services to surviving writers and readers (org).
(TOC) 2.3.8 AVAILABILITY/RELIABILITY
A. MROC Requirement. The DMS must provide users
with message service on an essentially continuous basis. The
required availability of the DMS should be achieved by a
combination of highly reliable and readily maintainable
components, thoroughly tested software, and necessary operational
procedures.
B. Characteristics.
1) Writer-to-reader system availability shall
be at least:
- 98.5 percent (org)
- 90.0 percent (ind)
2) Any failure or anomaly within the system
(writer-to-reader) shall not cause the delivery of a message to
the intended recipient, or alternate delivery location, to exceed
speed-of-service requirements (org).
3) Provide appropriate safeguards to protect
the system from accidental, unauthorized, or hostile actions that
could result in the inability to use system services (org/ind).
4) Provide contingency mechanisms for recovery
from accidental, unauthorized, or hostile actions that result in
the inability to use system services (org).
5) All system components shall have a common
time standard that is synchronized to within 30 seconds of the
UTC (org).
6) Provide for growth allowance, upon
implementation and without major re-design, of at least 25
percent to permit the upgrade of each component of the system in
areas of user connectivity and message throughput (org).
7) Provide the ability to expeditiously adapt
to changes in the number, type, location, and capability of
system users (org/ind).
8) Provide for alternate delivery capability
for intended recipient(s) (org)
9) Provide for multiple access for mission
critical message originators (org).
10) Provide the message originator with the
ability to override message recipient specified alternate
delivery (org).
11) The system shall be sized adequately to
preclude denial of service to writers and readers under normal
and stressed situations (org/ind).
(TOC) 2.3.9 EASE OF USE
A. MROC Requirement. The DMS must be flexible and
responsive enough to allow user operation without extensive
training. Use of the DMS should not require the knowledge of a
communications specialist.
B. Characteristics.
1) System training shall be developed and
provided, which, within a minimum period of time, enables message
originators and recipients, regardless of technical capability,
to submit and receive messages commensurate with their individual
responsibilities (org/ind).
2) All developmental components must meet the
design criteria outlined in MIL HDBK 761 and all COTS components
must meet the applicable ANSI standards (org/ind).
3) The writer shall be provided with the
ability to indicate the intended recipient(s) using aliases or
other mnemonics which do not require a complete knowledge of
intricate message addresses (org/ind).
4) DMS software applications shall conform to
the specifications outlined in the Center for Information
Management Human Computer Interface Style Guide.
(TOC) 2.3.10 IDENTIFICATION OF RECIPIENTS
A. MROC Requirement. The sender must be able to
unambiguously identify to the DMS the intended recipient
organizations or individuals. The necessary directories and
their authenticity are part of the DMS.
B. Characteristics.
1) The message originator must have the
capability to generate messages for single or multiple recipients
(org/ind).
2) The message originator must have the
capability to specify both action (primary) and information
(copy) recipient(s) for each message (org/ind).
3) Provide a directory capability that
supports the following:
a) Designation of intended recipient(s)
by directory name (org/ind).
b) Use of multiple addressing
capability (org/ind).
c) Recipient authorization/security
information (org/ind).
d) Alternate delivery for intended
recipient(s) (org).
4) Provide for the identification of traffic
restrictions which assists the message originator in limiting the
number of messages addressed to a specific organizational unit or
geographical location(s) (org/ind).
5) Traffic restrictions limiting the number of
messages addressed to a specific organizational unit(s) or
geographical location(s) will be enforced by message originators
(org/ind).
6) Provide the capability to selectively
restrict or discontinue the origination of messages (org/ind).
7) Provide for:
a) All intended recipient(s)
names/addresses visible to both the message originator and
recipient(s) (org/ind).
b) Some or all intended recipient(s)
names/addresses hidden from recipient(s) (org).
c) Some or all intended recipient(s)
names/addresses hidden from message originator (org).
8) Provide the ability to limit the maximum
number of intended recipients allowed per message, dependent upon
the needs and capabilities of the system (org/ind).
(TOC) 2.3.11 MESSAGE PREPARATION SUPPORT
A. MROC Requirement. The DMS must support
user-friendly preparation of messages for transmission, to
include services such as US Message Text Format (USMTF)
assistance.
B. Characteristics.
1) Provide the message preparer with "user
friendly" assistance in determining all information necessary to
complete a message (org/ind).
2) Provide clear means to discontinue
preparation, save, edit, and restart editing prior to submission
of a message (org/ind).
3) Provide for validation of the message
syntax and semantics prior to submission (org/ind).
4)* Provide for a message coordination
capability (either manual or automatic) (org).
* These capabilities may be provided by other external office
automation utilities.
(TOC) 2.3.12 STORAGE AND RETRIEVAL SUPPORT
A. MROC Requirement. The DMS must support storing
messages after delivery to allow retrieval for such purposes as
re-addressal, retransmission, and automated message handling
functions such as archiving and analysis, with the capability of
incorporating segments into future messages.
The minimum storage period for organizational
messages will be specified by Allied Communications Procedures.
B. Characteristics.
1) Support storage of messages allowing for
retrieval for such purposes as:
a) Re-addressal (org/ind)
b) Retransmission (org/ind)
c)* Automated message handling functions
(e.g. archiving and analysis) (org)
2)* Provide the capability for incorporating
segments of stored messages into future messages with appropriate
security protection (org/ind).
3)* Provide users with access to those stored
messages for which explicit access permission has been granted by
the appropriate authority (org).
4)* Provide at least 10 days message storage
capacity for organizational messages (org).
5) Provide for the storage and retrieval of
audit information. All audit information should be stored for at
least 30 days (org).
6) Storage of audit information pertaining to
classified messages should be handled IAW DOD 5200.1R (org/ind).
* These capabilities may be provided by other external office
automation utilities.
(TOC) 2.3.13 DISTRIBUTION DETERMINATION AND DELIVERY
A. MROC Requirement.
1) For organizational message traffic, the DMS
must determine the destination(s) of each message (in addition to
the addressee(s) specified by the message originator) and effect
delivery in accordance with the requirements of the
organization.
2) For individual message traffic, the DMS
must effect delivery of each message to the individual(s)
specified by the message originator.
B. Characteristics.
1) Provide the message originator with the
capability to specify special handling and delivery instructions
(org).
2) Must support single and multiple
deliveries, as well as single address lists that result in
multiple deliveries (org).
3) Provide the message originator with the
ability to specify special distribution criteria within the
message (i.e., subject) and support distribution determination
based on this special criteria (org).
4) Provide the message originator with the
ability to specify both primary (action) and information (copy)
addressees and assign different precedences for both (org).
(TOC)APPENDIX A - DEFINITION OF TERMS
Availability. Measurement of percentage of the time
during which a writer can submit a message and have it received
by the reader(s) within the required speed of service time.
Characteristic. These are the DMS requirements which
are derived from the DMS MROC requirements and are specified to a
greater degree of detail.
Defense Message System. All hardware, software,
procedures, personnel, and facilities required for electronic
delivery of messages between organizations and individuals in the
DOD.
Globally Unique Message Identifier. Message header
information which can be used to unambiguously identify a
particular message. Information which should be included, at a
minimum, is address of the message originator and date/time stamp
of origination.
Individual Messages. Working communications between
individuals within administrative channels, both internal and
external to the specific organizational element.
Intended Recipient or Reader. A human being or
automated process for which an individual message is addressed to
or an action official within an organization for which an
organizational message is addressed.
Message Delivery. When a message is available to be
read by the intended recipient.
Message Looping. The process by which a message
transits the same set of three or more message components
repeatedly, such that it is not delivered to the intended
destination.
Message originator or Writer. A human being or
automated process that drafts and sends an individual message or
that drafts and/or sends an organizational message for or as a
Message Release Authority.
Message Rate. Number of messages per day.
Message Receipt. When the intended recipient accesses
a delivered message.
Message Release Authority. A designated authority or
an automated process accredited by a Designated Approval
Authority (DAA) within an organization that has approval
authority to release organizational messages.
Message Shuttling. The process by which a message
transits the same two messaging components repeatedly, such that
it is never delivered to the intended destination.
Message Syntax. The manner in which message elements
are structured and combined. Message syntax defines the "format"
of the message.
Organizational Messages. Command and control
communications between organizational elements requiring approval
for transmission by designated authorities of the sending
organization, and determination of internal distribution by the
receiving organization.
Speed-of-Service. Writer-to-reader speed-of-service is
the time interval from which the writer of a message specifies
that the message is to be sent to the time at which the message
is available to be read by the reader.
Traffic Volume. Number of message characters per fixed
period of time.
(TOC)APPENDIX B - ABBREVIATIONS
ACP Allied Communication Publication
ANSI American National Standard Institute
ASCII American Standard Code for Information
Interchange
AUTODIN Automatic Digital Network
CAP Component Approval Process
COMPUSEC Computer Security
COMSEC Communications Security
COTS Commercial off-the-Shelf
DDN Defense Data Network
DMS Defense Message System
DOD Department of Defense
DODD Department of Defense Directive
ECP Emergency Command Precedence
FIFO First In First Out
IAW In accordance with
INFOSEC Information Security
LAN Local Area Network
MIL HDBK Military Handbook
MIL-STD Military Standard
MROC Multicommand Required Operational Capability
NSA National Security Agency
ROMC Required Operational Messaging Characteristic
TAIS Target Architecture and Implementation Strategy
TEMP Test and Evaluation Master Plan
US United States
USMTF United States Message Text Format
UTC Universal Time Coordinated
(TOC)APPENDIX C - LIST OF REFERENCES
Defense Communications Agency, May 1989, Automatic Digital
Network System Functional Specification, Washington, DC.
Defense Message System Coordination Office, October 1990, Defense
Message System Target Architecture and Implementation Strategy,
Washington, DC.
Defense Information Systems Agency, 12 February 1992, Human
Computer Interface Style Guide, Washington, DC.
Department of Defense, April 1990, DOD Directive C 5200.5,
Communications Security (COMSEC), Washington, DC.
Department of Defense, 1987, Defense System Software Development:
Military Standard 2167A, Washington, DC.
Department of Defense Directive 5200.28, 21 March 1988, Security
Requirements for Automated Information Systems (AIS), Washington,
DC.
Department of Defense, 1981, Human Engineering Design Criteria
for Military Systems, Equipment, and Facilities: Military
Standard 1472C, Washington, DC.
Department of Defense, June 1986, DOD Regulation 5200.1-R,
Information Security Program Regulation, Washington, DC.
Director of Central Intelligence (DCID), 19 July 1988, Security
Manual for Uniform Protection of Intelligence Processed in
Automated Information Systems and Networks (U), Washington, DC.
The International Telegraph and Telephone Consultative Committee
(CCITT), November 1988, Data Communication Networks Directory
Recommendations X.500-X.521, Blue Book, Vol. VIII, Fascicle
VIII.8, Geneva, SZ.
The International Telegraph and Telephone Consultative Committee
(CCITT), November 1988, Data Communication Networks Message
Handling Systems Recommendation X.400-X.420, Blue Book, Vol.
VIII, Fascicle VIII.7, Geneva, SZ.
The Joint Chiefs of Staff, 26 May 1981, Multi-command Required
Operational Capability for Automated Message Handling 9-81,
Washington, DC.
The Joint Chiefs of Staff, 6 February 1989, Multi-command
Required Operational Capability 3-88, the Defense Message System,
Washington, DC.
Joint Interoperability Test Center, March 1991, Defense Message
System Baseline Assessment Report, Fort Huachuca, AZ.
Public Law 100-235, 8 January 1988, Computer Security Act of
1987, Washington DC.
10 Aug 1995
|
|
|
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
|
|
|
|
|
|
