April 7, 1997
Part 01; INTRODUCTION/GUIDE AREA IPSC
Part 02; SOFTWARE ENGINEERING SERVICES
Part 03; USER INTERFACE SERVICES
Part 04; DATA MANAGEMENT SERVICES
Part 05; DATA INTERCHANGE SERVICES
Part 06; GRAPHICS SERVICES
Part 07; COMMUNICATIONS AND NETWORK SERVICES
Part 08; OPERATING SYSTEM SERVICES
Part 09; SYSTEM MANAGEMENT SERVICES
Part 10; SECURITY SERVICES
Part 11; DISTRIBUTED COMPUTING SERVICES
Part 12; MULTIMEDIA SERVICES
Part 13; HUMAN FACTORS SERVICES
Part 14; INTERNATIONALIZATION SERVICES
DISTRIBUTION STATEMENT A: Approved for public release; distribution unlimited
1. This document is approved for use by all Departments and Agencies of the Department of Defense (DOD).
2. Comments (recommendations, additions, deletions) and any pertinent data submitted for improvement of this document is addressable to the Information Processing Directorate (Code JEBE), Center for Standards (CFS), Joint Interoperability and Engineering Organization (JIEO), Defense Information Systems Agency (DISA), 10701 Parkridge Blvd., Reston, VA 20191-4357. E-mail Ms. Angela Booker at firstname.lastname@example.org or go to the DISA homepage at Http://www.itsi.disa.mil/. Please organize comments into two categories: "Essential" and "Suggested." Please include a recommendation and rationale for each proposed change. (See section 7.1 for complete instructions about commenting on this document.)
3. The Information Technology Standards Guidance (ITSG) is a tool. Its purpose is to define the DOD Open System Environment (OSE) and provide guidance to meet the requirement for consistent selection of base standards for profiles for DOD Information Technology (IT) acquisitions. It does this by defining the DOD OSE and the target group of IT standards that DOD systems are to use in implementations. The specification of the DOD OSE and the IT standards contained within that environment using the ITSG will guide system convergence toward the DOD-consensus target environment.
4. The ITSG is the foundation document for Technical Architecture Framework for Information Management (TAFIM) Volume 7, the Adopted Information Technology Standards (AITS). The ITSG is a resource supporting the Joint Technical Architecture (JTA) and the AITS by tracking activity in emerging standards that may someday appear in the JTA or the TAFIM. The ITSG also provides more detailed information about the standards adopted by the AITS, which is only a list of standards.
5. The ITSG specifies the IT standards available for each OSE base service area (BSA).
The ITSG identifies formal and emerging standards, bindings, public domain specifications, and the interrelationships among the recommended standards. It provides useful information on the recommended standards for each service area such as portability guidance and the recommended standard usage.
OVERALL ITSG TABLE OF CONTENTS
INTRODUCTION/GUIDE PART 1
SOFTWARE ENGINEERING SERVICES PART 2
USER INTERFACE SERVICES PART 3
DATA MANAGEMENT SERVICES PART 4
DATA INTERCHANGE SERVICES PART 5
GRAPHICS SERVICES PART 6
COMMUNICATIONS AND NETWORK SERVICES PART 7
OPERATING SYSTEM SERVICES PART 8
SYSTEM MANAGEMENT SERVICES PART 9
SECURITY SERVICES PART 10
DISTRIBUTED COMPUTING SERVICES PART 11
MULTIMEDIA SERVICES PART 12
HUMAN FACTORS SERVICES PART 13
INTERNATIONALIZATION SERVICES PART 14
TABLE OF CONTENTS1. Scope 1.1-
1.1 Scope 1.1-
2 GENERAL REQUIREMENTS 2.2-
2.1 Understanding open systems environments 2.2-
2.1.1 The role of standards 2.2-
2.1.2 Achieving practical, standards-based open systems 2.2-
2.1.3 Pitfalls of specifying only lists of standards 2.2-
2.1.4 Controlling the use of specific features of IT standards 2.2-
2.1.5 Conformance testing 2.2-
2.1.6 Relationship Between ITSG Standards and Weapon System Standards 2.2-
2.2 Structure of the ITSG 2.3-
2.3 How to use the ITSG 2.3-
2.3.1 Paragraph one: Standards 2.3-
126.96.36.199 ITSG standards type definition 2.3-
188.8.131.52 Standards entries 2.3-
184.108.40.206 The top row, DOD adopted information technology standard 2.3-
220.127.116.11 The emerging/declining standards, the "Gray Zone.\ 2.3-
18.104.22.168 Example table 2.3-
2.3.2 Paragraph two: Alternative specifications 2.3-
2.3.3 Paragraph three: Standards deficiencies 2.3-
2.3.4 Paragraph four: Portability caveats 2.3-
2.3.5 Paragraph five: Related standards 2.3-
2.3.6 Paragraph six: Recommendations 2.3-
2.4 Applicable Documents 2.4-
2.4.1 Government documents 2.4-
22.214.171.124 Specifications, standards, and handbooks 2.4-
126.96.36.199 Other government documents, drawings, and publications 2.4-
2.4.2 Non-government publications 2.4-
2.4.3 Standards availability 2.4-
188.8.131.52 International Organization for Standardization (ISO) standards 2.4-
184.108.40.206 ANSI standards 2.4-
220.127.116.11 Institute of Electrical and Electronics Engineers (IEEE) standards 2.4-
18.104.22.168 Government standards 2.4-
22.214.171.124 International Telecommunication Union (ITU) Telecommunications
Standardization Sector (TSS) standard 2.4-
2.4.4 Order of precedence 2.4-
2.5 Information Technology Standards Guidance Reference Model 2.5-
2.5.1 New Reference Model 2.5-
126.96.36.199 Introduction 2.5-
188.8.131.52 Problem 2.5-
184.108.40.206 Current ITSG Model 2.5-
220.127.116.11 ITSG Model 2.5-
2.5.2 ITSG Major Service Areas 2.5-
18.104.22.168 Software Engineering Services 2.5-
22.214.171.124 User Interface Services 2.5-
126.96.36.199 Data Management Services 2.5-
188.8.131.52 Data Interchange Services 2.5-
184.108.40.206 Graphics Services 2.5-
220.127.116.11 Communications and Network Services 2.5-
18.104.22.168 Operating System Services 2.5-
2.5.3 Proposed Rules 2.5-
2.6 Definitions 2.6-
2.6.1 Acronyms used in the ITSG 2.6-
2.6.2 Terms used in the ITSG 2.6-
2.7 Notes 2.7-
2.7.1 Comments 2.7-
3.1 Introduction/Guide 3.1-1
3.2 Software Engineering Services 3.2-1
3.3 User Interface Services 3.3-1
3.4 Data Management Services 3.4-1
3.5 Data Interchange Services 3.5-1
3.6 Graphics Services 3.6-1
3.7 Communications and Network Services 3.7-1
3.8 Operating System Services 3.8-1
3.9 System Management Services 3.9-1
3.10 Security Services 3.10-1
3.11 Distributed Computing Services 3.11-1
3.12 Multimedia Services 3.12-1
3.13 Human Factors Services 3.13-1
3.14 Internationalization Services 3.14-1
LIST OF TABLES2.2-1 Mapping service areas to parts 2.2-
2.3-1 Example table of basic database services standards 2.3-
2.5-1 Sample Global view of ITSG Model 2.5-
2.5-2 ITSG Major Service Areas Related to NIST APP and IEEE OSE/RM 2.5-
LIST OF FIGURES2.2-1 DOD Technical Reference Model 2.2-
2.3-1 Alternative specifications text example 2.3-
2.3-2 Standards deficiencies text example 2.3-
2.3.3 Portability caveats text example 2.3-9
2.3-4 Related standards text example 2.3-
2.3-5 Recommendations text example 2.3-
2.5-1 DoD Technical Reference Model 2.5-
1.1 Scope. The ITSG is intended for use by system engineers and program managers in planning and procuring an open information technology system by selecting standards profiles. The ITSG identifies the Open System Environment (OSE) Base Service Areas (BSAs) and the type and status of standards and specifications applicable to each BSA. Any BSA can include approved, open consensus, government standards, non-government standards, consortia and industry specifications, and other solutions. It also can include related standards that may be needed for a particular OSE BSA, caveats concerning the standards recommended that could jeopardize application portability, and information about how to tailor procurement specifications to avoid portability problems.
The standards arena is broad and is changing rapidly enough to make the ITSG quickly obsolete. The ITSG represents the consensus DOD target as it was best understood at the time of publication. The OSE defined in the ITSG reflects the considerations and realities of the marketplace and standards community. The goal of the CFS is to facilitate decentralized execution of IT program management leading to accomplishment of an enterprise-wide OSE. To that end, the ITSG will be updated on a recurring basis with sufficient frequency to maintain its relative currency and to expand the thoroughness of its coverage of the IT domain.
2. GENERAL REQUIREMENTS
2.1 Understanding open systems environments.
2.1.1 The role of standards. The fundamental premise of the ITSG is that the implementation of well aligned, standards-based open systems will lead eventually to a higher degree of interoperability and portability. Unfortunately, standards are not yet defined for all the basic services needed for all information technology systems. Additionally, standards usually contain multiple options. Many standards allow options whose use or disuse may result in systems that are compliant with the same standard yet are not interoperable with one another.
Vendors and industry organizations (i.e., consortia) have defined specifications (to augment a standard or to compete with a standard) to fill many gaps in the existing formal standards. These specifications can provide some limited portability and interoperability. Different standards-defining groups' specifications for satisfying the same basic services sometimes overlap and are incompatible even disregarding any options they may have. Identifying the basic services of a system requires a thoughtful and thorough understanding of system requirements for current and future information technology environments. After identifying the basic services, the recommended standards in the ITSG will provide a path toward the DOD consensus open system environment.
2.1.2 Achieving practical, standards-based open systems. A broad base of available standards is the basis for achieving open systems. Just choosing standards neither guarantees portability or interoperability nor guarantees easy integration of multi-vendor systems. Understanding the features and options of standards and knowing how to specify the standards is vital.
Information technology standards are layered in the architecture between the external environment and the platform or application environment. A well conceived architectural framework will list its functional requirements. The ITSG recommends standards intended to meet the functional requirements of the architecture.
2.1.3 Pitfalls of specifying only lists of standards. Profiling, which is a detailed description of the selection of options available within a standard, makes standards practical to use. However, many "open systems profiles" are only lists of standards, lacking the details to allow the standards to be implemented consistently for portability and interoperability.
The specification of lists of standards may indicate that the acquisition requirements have not been identified or considered fully. The use of standards requires the functional requirements of the system architecture be identified thoughtfully. The specification of only existing standards developed in a public consensus standards committees does not take advantage of other potential solutions available to fill other functionality areas with some form of standards implementation where such formal standards do not exist. For example, a Request for Proposal (RFP) may specify certain required Government standards or Non-Government Standards (NGS) and indicate those areas for which the bidder must propose standards. The system design areas that have a functionality requirement not supported by adopted standards must be evaluated carefully for life cycle implications with respect to the DOD open systems environment objective.
Specification of standards by their names is not sufficient. Requirements exist for the specification, use, and exclusion of specific dependencies, extensions, and features that are implementation-defined, implementation-dependent, undefined, or unspecified within a standard. A standard's libraries, library functions, modes, options, and switch settings used in the product implementation of a standard have portability implications. International Organization for Standardization (ISO) TR-10000 and MIL-HBK-829 cover the requirement for detailed profiles more extensively.
2.1.4 Controlling the use of specific features of IT standards. Standards' features (e.g., options, extensions, levels) must be controlled within system development. Standard features adverse to future system portability must be excluded. The PM must exclude hostile and obsolete features of a standard which will impede future system portability.
2.1.5 Conformance testing. Testing implementations for conformance to a required standard is necessary. Where National Institute of Standards and Technology (NIST) conformance tests exist, validated products lists are available that will indicate the Federal Information Processing Standard (FIPS) and the individual point of contact responsible for the standard's conformance testing program. A NIST report on conformance testing and validated products can be located at ftp://speckle.ncsl.nist.gov/vpl/intro.htm.
The Open Group (X/Open) validates products through its branding program. More information regarding X/Open branded products can be located at URL http://opengroup.org/.
The DOD's Joint Interoperability Test Command (JITC) maintains a list of products it has tested. The list can be located at URL http://jitc-emh.army.mil/register.htm.
2.1.6 Relationship Between ITSG Standards and Weapon System Standards. The standards in the ITSG have a much broader range of applicability than just information processing systems. They are equally applicable to other systems, such as weapon systems. ITSG standards in major service areas such as data interchange, operating systems, and security are as needed by many weapon systems as Mission Critical Computer Resources (MCCR) standards are.
Among the major service areas of the ITSG that contain standards useful to military weapon systems are user interface (e.g., keyboard device layout, user interface style guides), data management (e.g., data dictionary/directory services), data interchange (e.g., physical interface, image data interchange, geospatial data exchange, tactical communications), graphics (e.g., symbology graphics), communications, (e.g., connectionless service), operating systems (e.g., real time services and interfaces), system management (e.g., fault monitoring), and security (e.g., authentication).
2.2 Structure of the ITSG. The ITSG aligns with the major service areas in the reference model in Figure 2.2-1 below, which comes from TAFIM Volume 2, the Technical Reference Model.
FIGURE 2.2-1. DOD Technical Reference Model
The major service areas in the ITSG are covered in detail in Section 3, Detailed Requirements. Because it is so large, Section 3 is divided by major and spanning service areas into separate parts of this document. After reading part one, the Introduction/Guide, the user can treat the ITSG more like an encyclopedia, exploring the standards solutions for service areas of interest. Table 2.2-1 lists the sections and the seven major and six spanning service areas along with the CFS point of contact (POC) for each. ITSG parts 2 through 8 list the major service areas; parts 9 through 14, the spanning service areas. Sections 22.214.171.124 and 5.2.2 contains further information regarding spanning and major service areas.
TABLE 2.2-1 Mapping service areas to parts
(Name, Office Code)
1, 2, 3.1, 4, 5, 6, 7
Ms. Angela Booker, JEBEA
Mr. Jim Barnette, JEBEB
Dr. Dan Wu, JEBEB
Mr. Alan Peltzman, JEBEB
Mr. Alan Peltzman, JEBEC
Communications and Network
Mr. Ralph Liguori, JEBBD
Mr. Curtis Royster, JEBEB
Mr. Larry Spieler, JEBEA
Mr. Jim Barnette, JEBEB
Dr. Dan Wu, JEBEB
Dr. Doris Bernardini, JEBEB
Ms. Angela Booker, JEBEA
Each major service area in parts 2 through 14 is decomposed into dozens of smaller service areas called BSAs. There are additional services below the base standard, but the ITSG does not attempt to represent them. These lower levels usually involve only small parts of standards, not entire documents. Every BSA within the anticipated DOD Open System Environment is in the ITSG. For a DOD system or architecture to proceed toward an open system goal, the architectural requirements of the system must match up to these BSAs. The BSAs also show some logical relationships that lead to identifying mid-level service areas within the major service areas.
For example, the Data Management Services major service area breaks down into mid-level service areas as follows:
a. Data management system
b. Data management security
c. Data dictionary/directory services
d. Distributed data
e. Object database
f. Transaction processing.
Within the mid-level service area called "data management system," the ITSG contains the following OSE BSAs. An example of one of these OSE BSAs follows in section 2.3.
a. Basic database services
b. Indexed sequential access
c. Electronic forms
d. Report writer
e. Database administration
f. Menu-driven database access
g. Data storage and archiving
h. Multidatabase APIs.
2.3 How to use the ITSG. The BSA descriptions are the focus of the use of the ITSG. These descriptions are in parts 2 through 14. The major and mid-level service area descriptions are no more than definitions of the logical links binding all the BSAs grouped beneath them.
A BSA is a logical entity within the OSE that requires some form of standards solution although not all BSA descriptions have standards solutions yet. Some standards logically fall within a specific BSA. In other cases, different BSAs sometimes list the same standards because a particular standard satisfies more than one BSA requirement. For each BSA identified, there is a brief definition of the BSA, and the following topics are addressed:
3.X.Y.Z.2 Alternative specifications.
3.X.Y.Z.3 Standards deficiencies
3.X.Y.Z.4 Portability caveats
3.X.Y.Z.5 Related standards
In each BSA there are five paragraphs giving additional explanation of the standards listed in the standards table of the first paragraph. The standards listed in the top rows (labeled DOD "mandated" or "adopted") are given primary emphasis. The text is intended to support primarily the mandated standard. Information about the remaining standards provides assistance for the DOD legacy systems that may continue to use other standards during their transition to the DOD OSE target environment. In those sections for which no information can be reported at present, a short statement will appear stating that there is no known or reported information on this topic. Information may be added in future versions of the ITSG. An example of text that corresponds to the example standards table follows in sections 2.3.2 through 2.3.6.
2.3.1 Paragraph one: Standards. The first sub-part of the BSA description is the standards table. The standards table is the key to using the ITSG. These tables include all applicable standards satisfying the BSA. The intent is to list all of the standards that may be used within DOD to prepare for the non-open legacy systems that will be migrating toward open systems. These systems may implement standards other than the recommended ones.
It is important to remember that the standards table is not a stand alone expression of the DOD OSE recommendation. Paragraph six, the recommendation, must also be consulted for the rationale for the recommendation. Each table must be viewed in the context of the additional text provided in the BSA to understand fully the recommendation and its implications.
The following features in the standards table require further explanation:
a. Standards types and hierarchy of standards
b. Standards entries
c. The DOD adopted information technology standard
d. The "Gray Zone."
126.96.36.199 ITSG standards type definition. The ITSG defines standards types using three descriptors. These descriptors define the scope of the sponsoring body, the availability of the specification, and the method of change control in defining or redefining the specification. This standards type definition is most useful for distinguishing among the many kinds of public specifications that are preferred in the aftermath of the cancellation of MIL-STD-970.
188.8.131.52.1 Scope. This identifies the range of intended applicability of the specification, determined largely by the sponsoring body. The permitted values for the scope descriptor are International, National, Government, Consortium, or Corporate. The latter value identifies specifications created by a single company for their own use but which may be available to others. Examples of this type include data storage formats specific to software products.
184.108.40.206.1.1 International. Standards of international scope are NGS created by accredited international NGSBs. For NGS, there is an order of precedence cited by the IEEE in P1003.0, and adapted here. The order is international standards, regional standards, national standards, draft versions of the preceding, open forum standards (e.g., professional group standards, trade association, industry, consortia), emerging (e.g., committee documents, draft regional or national standards), and de facto. Typical international NGSBs include the International Telecommunications Union (ITU) and International Organization for Standardization (ISO).
220.127.116.11.1.2 National. Standards of national scope are NGS created by accredited national NGSBs. Typical national NGSBs include the Institute for Electrical and Electronics Engineers (IEEE) and American National Standards Institute (ANSI).
18.104.22.168.1.3 Government. Standards of government scope are those standards developed or adopted by departments and agencies of the Federal government. These standards can be and often are identical to existing NGS. At times, the government mandates specific standards by law. The most important part of mandated standards (for ranking purposes) is the source of the mandate, whether by law (FIPS), DOD (JTA or OSD Directive), treaty and/or international military standardization agreement (e.g., NATO STANAG, Air Standardization Coordinating Committee). In this document, the only mandatory standards are those mandated by the JTA, and those JTA mandated standards come first in precedence. (See para. 22.214.171.124.5.1.1 for a description of Mandated status.)
126.96.36.199.1.4 Consortia. Consortia include organizations not formally recognized and accredited to make standards. Suppliers and users of information technology unite to create consortia standards. Increasingly, consortia are defining specifications that provide needed extensions to national and international standards because these standards bodies cannot anticipate users' requirements in all aspects of computing and define standards quickly enough. Sometimes these extensions arise from the NGSBs' inability to agree on a proposed portion of a standard. Consortia specifications also are created in response to the absence of standards for a needed service.
Consortia specifications achieve consensus outside of accredited NGSBs and use a consensus process for their maintenance. This consensus process of creating specifications, while not entirely open (sometimes open only to trade associations, industry groups, and individual vendors), enables products that support portability and interoperability to be implemented. Many standards-creating consortia use a consensus process to maintain the standard, although the process may not be open. Also, such maintenance decreases the chances the applications and platforms become incompatible.
These specifications frequently become the basis for standards from NGSBs later (e.g., OSF's Motif specification became the basis for IEEE 1295.1). Most consortia specifications are available now, do not overlap with or conflict with an existing NGS or NGS under development, and exercise no restraint (except perhaps cost) on who can use the specifications or how they can use them.
188.8.131.52.1.5 Corporate. Software developers also develop standards for their own use that are not generally consensus standards. These are incorporated in software products, achieve a high degree of popularity, and become known as de facto standards. The specifications for these systems are under proprietary control. A vendor's unilateral change to their corporate standard may make other vendors' products and applications that originally were compatible incompatible. Proprietary or corporate standards are to be used only when no available commercial or government standards will support the requirement. Acquisition policies prohibit using such specifications in the same manner that the other standards in an RFP are used. The ITSG does not recommend nor specify corporate standards.
184.108.40.206.2 Availability. This identifies whether the specification is available to the Public, or if it is Private. In order to be Public, a specification must be available to anyone for a reasonable cost (i.e., for reproduction cost). Specifications that are only available to dues-paying members of a consortium are Private. Payment for a standard on a license basis rather than dues payment to a group also belongs to the Private category.
220.127.116.11.3 Change control. This identifies whether changes are controlled by a Consensus or Non-consensus process. Accredited NGSBs and the government produce standards controlled by a consensus process, since the affected organizations are given a chance to express comments before the standard is approved. A consortium may be considered to have a consensus process if the membership of the consortium is not restrictive (other than by the cost of membership). A specification controlled by a single profit-making organization is not changed by a consensus-based process.
18.104.22.168.4 Abbreviations. Some of the most used standards types will appear in abbreviated form. These types and their abbreviations are:
Corporate Private Non-Consensus (CPN-C)
Consortia Public Consensus (CPC)
Government Public Consensus (GPC)
International Public Consensus (IPC)
National Public Consensus (NPC)
22.214.171.124 Standards entries. This section describes the entries in the different columns of each standards entry in the standards table.
126.96.36.199.1 Standard type. The first column in the standard entry is the standard type as discussed in 188.8.131.52, ITSG standards type definition, above.
184.108.40.206.2 Sponsor. This column identifies the organization sponsoring or controlling changes to the specification or standard. Typical sponsors are ISO, ANSI, IEEE, NIST, or X/Open.
220.127.116.11.3 Standard. This column identifies the standard or specification by name. Many standards with different designations are identical (e.g., standards adopted by multiple standards bodies without changes). A specific example is IEEE Std. 1003.1-1990, which ISO later adopted as ISO/IEC 9945-1:1990, and NIST as FIPS PUB 151-2. The standards tables contain all the references to identical standards in separate rows using each of their different designations. If the specification is the same as, or derived from another standard, the relationship is indicated with comments to the effect in the same column. This approach toward matching standards has been chosen for informative reasons.
18.104.22.168.4 Standard reference. This column contains a formal citation for the standard or specification. The citation must include a version number and date, if necessary to unambiguously identify the specification.
22.214.171.124.5 DOD status (Life Cycle status). This column identifies the status of the specification, from concept to obsolescence. This column identifies both the DOD status and the ITSG life cycle status. The allowable values for each type of status reported are discussed in the sections that follow. All entries in the tables show the life cycle status in parenthesis. DOD status may or may not apply to the standard.
126.96.36.199.5.1 DOD status. This part of the DOD status (Life Cycle status) column refers to the approval for use of a standard in the DOD community according to the JTA or the TAFIM. DOD status terms include mandated, adopted, emerging, legacy, and informational. These terms are discussed in the following subparagraphs.
188.8.131.52.5.1.1 Mandated. The DOD status "Mandated" is used for those standards mandated by the JTA. A standard is mandatory in the sense that IF a service/interface is going to be implemented, it shall be implemented in accordance with the associated standard. If a required service can be obtained by implementing more than one standard, the appropriate standard should be selected based on system requirements. Mandated standards appear in the top rows of the standards tables in the ITSG and are bordered with heavy black lines.
184.108.40.206.5.1.2 Adopted. The DOD status "Adopted" is used to mean that the standard in the ITSG is approved by DOD for use in satisfying each function of the BSA where there exists no JTA mandated standard. Adopted standards may be implemented but shall not be used in lieu of a mandated standard. Adopted standards also appear in the top rows of the standards tables in the ITSG and are bordered with heavy black lines.
220.127.116.11.5.1.3 Emerging. According to the JTA, a DOD "Emerging" status denotes a candidate standard to be added as, or to replace, a mandated standard. This includes standards required to capitalize on new technologies. These candidates will help the program manager determine those areas that are likely to change in the near term (within three years) and suggest those areas in which "upgradability" should be a concern. The expectation is that emerging standards will be elevated to mandated status in the JTA when implementations of the standards mature. Emerging standards may be implemented but shall not be used in lieu of a mandated standard.
18.104.22.168.5.1.4 Legacy. A "Legacy" standard is a standard necessary to achieve or maintain interoperability with legacy systems. Legacy systems are systems that are in current use. Legacy standards are not recommended for future procurements. Legacy standards may be supported until the legacy system is no longer being maintained. An example of a legacy standard is the X.25 packet switching standards.
22.214.171.124.5.1.5 Informational. Informational standards include those remaining standards that fall outside the official DOD statuses of "mandated," "adopted," "emerging," and "legacy."
126.96.36.199.5.2 Life Cycle status. This part of the DOD status (Life Cycle status) column defines the life cycle status of the standard, as established by the originator of the standard.
188.8.131.52.5.2.1 Approved. The specification has been approved and published by its sponsoring body. This status is only meaningful for consensus-based specifications and standards.
184.108.40.206.5.2.2 Superseded. Superseded standards were formerly approved but have now been replaced, either by a later version of the standard or by the progress of technology. Superseded standards are not often desirable, but rank ahead of any non-approved standard. Superseded standards appear only at the bottom of the standards table.
220.127.116.11.5.2.3 Draft. The specification has been defined and is being reviewed. If this is a public, consensus standard, the specification should be available for comment. Draft standards are often subject to significant change before approval.
Further notes are appended to clarify the status of a draft, including the ISO stages of development (e.g., CD, WD, DIS) or if the standard is in ballot.
Draft standards appear only at the bottom of the standards table.
18.104.22.168.5.2.4 Formative. The specification is in the process of being defined. Generally, a committee has been formed to create the standard, but the specification has not stabilized. It is not available to the public. Formative standards appear only at the bottom of the standards table.
22.214.171.124 The top row. The top rows of the standards table contain the DOD mandated or adopted information technology standard satisfying that particular BSA. These standards are surrounded by a heavy black line and the standards are the same ones presented in the Adopted Information Technology Standards (TAFIM Volume 7).
The remaining five parts of the BSA description provide additional and necessary information about the target standard and the other standards listed in the table. The extensive information about the standards population within a specific BSA provides a full perspective of the activity in that area. The standards in the lower rows are provided in case an acquisition cannot use the standard specified in the top row. For example, they may be transitional systems in which a portion of a legacy system will remain unchanged temporarily.
If a standard listed in a lower row is specified in an acquisition, then the acquired system will diverge from the target DOD OSE. Standards listed in the lower rows of the tables diminish the probability of achieving portability and interoperability and may increase the ultimate life-cycle cost required to achieve an open system state.
If a system cannot use the standard specified in the top row, then it would be preferable to use a standard listed in a lower row, but within the standards table if possible. If a standard listed in a lower row is specified, there is risk. This risk is two-fold. If an emerging standard listed in a lower row is specified, the emerging standard may fail to arrive in the marketplace in the same form within a product. If the system implementation uses a declining standard of diminishing use and popularity, there is a risk that the products implementing the standard may be dropped by vendors as they move toward the standard listed in the top row. Projects using standards not consistent with the target standards identified in this document preclude the levels of portability and interoperability required to satisfy these stated DOD requirements. Also, the text accompanying the BSA contains further needed guidance for a solution.
The standards tables of some BSAs show what may be considered a paradoxical situation. There may be more than one "top row" standard. This occurs, for example, in the geospatial data area where different data sets are appropriate to different map scales. This situation shows that more than one standard may be preferred depending on specific architectural requirements. Often these multiple standards are complementary and all could be chosen to achieve the desired results.
126.96.36.199 The bottom area. The contents of every standards table in the ITSG will change as a reflection of industry dynamics as standards become formalized and are drafted, or become obsolete and superseded. The bottom area in the tables depicts this rise and fall of standards. The bottom area can contain standards with life-cycle statuses superseded, formative, and draft with DOD statuses emerging, legacy, or informational. The specification of standards within the bottom area involves risk. These standards are only an option in the case where no suitable NGS is listed in the upper rows. Populated bottom areas tend to show up in established BSAs containing many different standards.
188.8.131.52 Example table. All standards found in the remaining parts of the ITSG are combined under section 3.X.Y.Z.1 into a single table. Table 2.3-1 gives an example of a standards table using a BSA from the example of the ITSG structure in section 2.2. Note that Table 2.3-1 and figures 2.3-1 through 2.3-5 are to be used as examples and not as the official findings of the BSA used in these examples.
In the example of a standards table below, the top row, or DOD mandated standard, is NIST FIPS 127-2, specifying Database Language SQL. This version of the SQL standard uses ANSI X3.135-1992 and ISO 9075:1992. The mandated standard has precedence over all other entries in the table and should be used. The first entry in the bottom area of the example table is in draft (CD) life-cycle status and is DOD informational. Risk is less for this draft standard than for the DOD informational superseded standard appearing in the bottom area. The superseded life-cycle standard has been replaced and, therefore, involves much risk, if used. (In fact, it should not be used at all.) The last entry in the bottom area has a draft life-cycle status with DOD informational status. As is noted, it may eventually replace SQL2. This last standard will be moved out of the bottom area if and when it is approved by its sponsoring body. If JTA decides to add it to its emerging list, then the DOD status "emerging" will replace the "informational" DOD status. The standard would then appear above the bottom area as DOD emerging with life-cycle status of approved. [Note: Risk factors are usually different for each information system. It is the responsibility of the program manager to determine risk by performing a risk analysis. Risk determination is beyond the scope of the ITSG.]
TABLE 2.3-1 Example table of basic database services standards
Database Language SQL (Adopts ANSI X3.135-1992 and ISO 9075:1992)
Database Language SQL (same as ANSI X3.135-1992)
Database Language SQL (same as ISO/IEC 9075:1992)
Guidelines for Functional Specifications for Database Management Systems
Embedded SQL (COBOL and C)
SQL Developers Specification
Database Language - Network (NDL)
Database Language - NDL (adopts ANSI X3.133-1986)
Database Language - (NDL)
Data Management: Reference Model
Database Language SQL3 (will replace SQL2)
Structured Query Language (SQL)
(Formative (FIPS Planned))
Database Language SQL3 (will replace SQL2)
X3H2 Project 0525-R
2.3.2 Paragraph two: Alternative specifications. The "Alternative specifications" section identifies other specifications that can satisfy the BSA. These will often be de facto specifications or vendor products that are de facto standards and other specifications not defined in formal standards groups. The DOD and ITSG's policy is generally NOT to recommend such specifications. The alternative specifications indicate the types of solutions likely to be offered if no other specifications exist.
FIGURE 2.3-1 Alternative specifications text example
The following alternative specifications are available:
a. For data definition, manipulation, query, data integrity, embedded SQL, and dynamic facilities standards: Integrated Database Application Programming Interface (IDAPI), a specification, published by Borland, IBM, Novell, and Word Perfect Corporation, will allow DOS, OS/2, and Windows applications to access a variety of SQL and non-SQL databases transparently.
b. No applicable consortia or de facto SQL integrity constraint specifications are available.
c. For X/Open SQL and the IBM Systems Application Architecture (SAA) SQL support Embedded C.
d. For dynamic facilities the only other available specifications are proprietary.
In the alternative specifications example, several alternatives are mentioned, but they are not appropriate considering the availability of SQL in FIPS 127-2.
2.3.3 Paragraph three: Standards deficiencies. This section identifies deficiencies in the standards and recommends how to apply the standard to reduce their impact. "Standards deficiencies" addresses known problems within the standards such as missing features. In those cases where this section is absent, no deficiencies have been identified for inclusion, but does not suggest the standards have no deficiencies.
FIGURE 2.3-2 Standards deficiencies text example
The following deficiencies in the standards have been identified:
a. For data definition, manipulation, query, data integrity, embedded SQL, and dynamic facilities standards:
(1) No standardized way exists to specify logical database access control, which is important to database security.
(2) Hashing methods to access data are neither standardized nor in progress.
(3) SQL1 is inadequate and has failed to be transportable or standardized to be very useful. The upcoming SQL-3 provides an opportunity for DOD requirements to be inserted.
b. For data integrity standards, SQL Integrity Enhancement is a simple capability with no constructs to help programmers maintain data consistency.
c. For Embedded SQL standards, SQL2 supports Embedded SQL in C and Ada. However, products will not be available for some time. International Organization for Standardization (ISO)/American National Standards Institute (ANSI) Embedded SQL does not support the
FIGURE 2.3-2 Standards deficiencies text example (cont'd.)
C programming language. The use of embedded SQL requires a precompiler for each language in which SQL is embedded.
d. For dynamic facilities standards, deficiencies in the existing formal standards are unknown.
e. For SQL environments, the emphasis in this first FIPS for SQL Environments is on profiles for limited SQL interfaces to non-SQL data repositories. Subsequent versions of this FIPS may specify more complete profiles for other products in an SQL environment. The profiles defined by this standard are not complete in and of themselves. The user is required to add information before this standard can be successfully used in a procurement.
In the standards deficiencies example above, several problems with the existing standards have been identified. In this example, no deficiencies in FIPS PUB 127-2 have been identified.
2.3.4 Paragraph four: Portability caveats. "Portability caveats" addresses the features of the standard hindering portability. In those cases where this section is absent, no portability problems have been identified, but the absence of portability caveats does not suggest the standards have no portability problems.
The portability caveats example points out particular problems of the SQL standards: implementation-defined exception code values and the character data type. Additional portability problems arise between the NIST FIPS for SQL and the other versions of the standard as shown in the text. (See Figure 2.3-3).
FIGURE 2.3-3 Portability caveats text example
The following portability caveats apply:
a. For data definition, manipulation, query, data integrity, embedded SQL, and dynamic facilities standards,
(1) SQL 2's segmentation into multiple levels increases the likelihood of incompatibility between different vendors' SQLs, because different vendors will implement entry level SQL 2, then choose options from other levels.
(2) The ISO, ANSI, and Federal Information Processing Standard (FIPS) versions of SQL specify state exception code values (called SQLCODE parameters) such as 0 for successful execution, 100 for nonexistent data, and implementation defined code values for particular exception conditions. Different products that conform with SQL have different SQLCODE values for exception conditions. The set of SQL character values for the character data type and collating sequence of characters is defined by the implementor, the implementor, and therefore, nonstandard in products.
b. For data integrity the following portability caveats apply:
(1) Most vendors' products contain extensions. To maximize portability, reduce the use of extensions as much as possible.
(2) Different vendors provide locking to different degrees of granularity. Portability and/or interoperability of applications result in locking to the largest degree of granularity.
FIGURE 2.3-3. Portability caveats text example (cont'd.)
c. For dynamic facilities the following portability caveat applies: Although the X/Open and SAA SQLs support dynamic SQL, X/Open SQL is an X/Open-enhanced specification of the 1986 version of Level 1 SQL, while SAA SQL is not fully ISO/ANSI SQL compatible, although it will be. Also, X/Open and SAA dynamic SQL facilities are not fully compatible with each other.
d. For SQL environments, conformance testing for products claiming conformance to one of the profiles specified by FIPS 193 will be achieved by a suitable modification of the existing NIST SQL test suite. This FIPS requires the customer to choose from among the different binding styles already defined by the SQL standards. Two of these styles (CLI and RDA) are expected to be more popular than the others. If a programming language binding style is chosen, then FIPS SQL specifies the parameter passing requirements for each of seven different programming languages.
2.3.5 Paragraph five: Related standards. The related standards section addresses the standards required as a foundation for a particular standard, or other standards relating to the functionality under discussion, or other interfacing standards. A prime example of this would be IEEE Std. 1003.1-1990 as a related standard for using IEEE P1003.1b, which is the real time extension to the 1003.1 standard.
In the related standards example, standards usable to extend SQL functionality have been identified. These standards include Remote Database Access (RDA), and all may be found in the standard tables of other BSAs in section 3.4. (See Figure 2.3-4).
FIGURE 2.3-4 Related standards text example
The following standards are related to basic database services or basic database service standards:
(1) ISO 9579-1: Remote Database Access (RDA) (Generic Model, Service and Protocol) (supports remote database access in client-server environments)
(2) ISO 9579-2: RDA: (SQL Specialization)
(3) SQL Access Group's (SAG's) SQL Access Formats and Protocols (FAP) (1991)
(4) SAG's Call Level Interface (CLI)
(5) X/Open RDA Preliminary Specification (Identical to the SAG's RDA Specification
(6) X/Open's CLI Snapshot Specification (Identical to the SAG's CLI Specification)
(7) Open Systems Interconnection (OSI) CCR (Commitment, Concurrency, and Recovery): ISO/International Electrotechnical Commission (IEC) 9804-3/9805-3
(8) OSI Distributed Transaction Processing (DTP) Protocol: ISO/IEC 10026 Parts 1, 2, and 3.
(9) ISO 1989:1985: COBOL
(10) ANSI X3.9-1978: FORTRAN-77
(11) ANSI X3.159-1989: C
(12) National Institute for Standards and Technology (NIST) FIPS 021-3: COBOL
(13) NIST FIPS 069-1: FORTRAN
(14) NIST FIPS 119, DOD MIL-STD 1815A:1983, ISO 8652: Ada
FIGURE 2.3-4 Related standards text example (cont'd.)
(15) NIST FIPS 160: C
(16) ISO/IEC Draft International Standard (DIS) 10032: Reference Model of Data Management
(17) ISO 12227 SQL/Ada Models Description Language, 1994
(18) X3 SQLIB-1 SQL Information Bulletin Number 1 Interpretation of ANSI X.3.135 - 1989
2.3.6 Paragraph six: Recommendations. "Recommendations" advises which standard is preferred for specification in the procurement for the particular area of functionality and standards. The recommendation will provide suggested wording to use in the procurement when possible. Additional guidance about selection of options and features of a standard is also included as potential solutions to the portability problems identified above.
In these example recommendations, the most current SQL and supporting standards are recommended with details about optional conformance levels and testing. (See Figure 2.3-5).
FIGURE 2.3-5 Recommendations text example
a. The following are related to data definition, manipulation, query, data integrity, embedded SQL, and dynamic facilities standards:
(1) Consult the wording suggested in the October 1991 General Services Agency (GSA) publication for proposed language for requiring that a database conform to SQL, and consult FIPS 127-2 for guidance on how to structure a Request for Proposal (RFP). The FIPS "flagger" (to flag nonconforming extensions) is optional and must be specified explicitly.
(2) If interactive SQL is required, a procurement must indicate explicitly whether or not "direct invocation of SQL statements" is required and, if required, which SQL statements are to be directly invocable. If not specified, the default is "CREATE TABLE," "CREATE VIEW," "GRANT privilege," "SELECT" with "ORDER BY" option, "INSERT," "UPDATE:searched," "DELETE:searched," "COMMIT WORK," and "ROLLBACK WORK."
(3) Explicitly specify sizing constraints for database constructs. The FIPS 127-2 sizing specifications are reasonable to expect vendors to deliver, but are fairly minimal. Since database construct sizing specifications depend on the procurement, a procurement can override them.
(4) Require the use of NIST conformance tests and/or services to validate conformance to the SQL-based FIPS for required and optional FIPS 127-2 features. Testing applies only to a specific platform, so call for conformance tests for each platform bid. Use the quarterly list of processors validated against FIPS 127-2 by NIST to help evaluate bids.
(5) Specify the NIST's Transition Level SQL 2 and the SAG's CLI and RDA interfaces and protocols for the following reasons. Most DBMS vendors have no intention of conforming to the Full Level SQL 2:1992 because it is very large and complex. As a result, the time it will take to add the necessary features will probably exceed the time before the SQL 3
FIGURE 2.3-5 Recommendations text example
standard is completed. To ensure portability as well as functionality, users are encouraged to include the following two specifications in their procurement:
(a) NIST's Transition Level SQL 2 (specified in FIPS 127-2), which is a hybrid of Entry Level and higher levels of SQL 2:1992.
(b) SAG's and X/Open's CLI and RDA standards. The SAG specifications are not segmented like SQL '92 and offer a nice balance between the Full Level SQL '92 feature set and what users need now. The SAG specifications include connection management capabilities (which are part of the SQL '93 Full Level), schema manipulation and the CHARACTER VARYING data type (both of which are part of SQL '93 Intermediate Level), and features not included in any level of SQL '92 conformance, including the CREATE INDEX and DROP INDEX statements. SAG's specifications are published jointly with X/Open as X/Open specifications.
(6) Specify SQL2 (and later SQL3) as soon as possible because SQL2/3 contains greater standardized functionality than SQL1. This will reduce the use of nonstandard extensions. SQL2 also standardizes more than 60 SQLCODE exception code values.
(7) Carefully specify and check all sizing constraints for a procurement to meet functionality requirements and avoid portability problems.
(8) Avoid the Network Data Language (NDL), if possible, because it is little used and will not be upgraded.
(9) Specify the ISO RDA standard, and also the X/Open or SAG's RDA and CLI specifications in conjunction with SQL/SQL2 to obtain remote data access capabilities in a distributed environment.
b. The Integrity Constraint feature is optional in SQL and must be specified explicitly for a procurement. Failure to do so means the Integrity Constraint feature is not required. Specify FIPS 127-2, especially if any of the services unique to FIPS 127-2 are needed.
In SQL2, the integrity enhancement feature is mandatory, not optional. Also, SQL2 has better integrity constraints, such as "cascade delete on referential integrity" (in the intermediate SQL Level) and "deferrable integrity constraints" (in full SQL2).
c. For embedded SQL:
(1) Specify embedded SQL in an RFP, although it is optional in the standard. Indicate which programming language is to be supported in references to embedded SQL in a procurement. Failure to do so means that support for any one FIPS language satisfies the FIPS SQL requirement. Indicate whether the language interface is to support the Module Language interface style, the embedded language interface style, or both. Failure to do so means that vendors supporting any one interface style satisfy the FIPS SQL requirement.
(2) Require the use of NIST conformance tests and/or services to validate conformance to every one of the embedded interfaces and module interfaces, and to validate the compilers that will be used with the embedded SQL because SQL testing is independent of the host programming language testing. Testing applies only to a specific platform, so call for conformance tests for each platform bid. Specify FIPS 127-2 if any of the services unique to FIPS 127-2 are needed. Specify that the character data values and collating sequences coincide with the character values and collating sequence of the specific programming languages to be used. Failure to indicate specific character set requirements means that support for representation of the 95-character graphic subset of American Standard Code
FIGURE 2.3-5 Recommendations text example
for Information Interchange (ASCII) (FIPS 1-2) in an implementor specified collating sequence defaults to the minimum requirement, and may not be portable across other procured systems.
d. For dynamic facilities, SQL2 is preferred. Dynamic SQL is an intermediate level SQL2 capability. Either SQL2's dynamic SQL facilities or the SQL2 intermediate level must be specified explicitly in a procurement.
e. For SQL Environments, the FIPS is applicable in any situation where it is desirable to Integrate user productivity tools and heterogeneous data repositories into an SQL environment. It is particularly suitable for specifying limited SQL interfaces to legacy databases or to specialized data repositories such as geographic information systems, full-text document management systems, or object database management systems.
2.4. Applicable Documents
2.4.1 Government documents.
184.108.40.206 Specifications, standards, and handbooks. The following specifications, standards, and handbooks form a part of this document to the extent specified. Unless otherwise specified, the issues of these documents are those listed in the issue of the DODISS and its supplement. Other specifications, standards, and handbooks referred to in the text of this document are also included to the extent specified.
DOD Directive 5000.1, Defense Acquisition, 15 March 1996.
DOD Regulation 5000.2-R, Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs.
DODD 4120.3-M, Defense Standardization Program, 7 July 1993.
220.127.116.11 Other government documents, drawings, and publications. The following other government documents, drawings, and publications form a part of this document to the extent specified herein. Other government documents, drawings, and publications referred to in the text of this standard are also included to the extent that this document specifies.
NIST Special Report 500-230, Application Portability Profile (APP): The U.S. Government's Open System Environment Profile, version 3.0, December 1995.
Technical Architecture Framework for Information Management (TAFIM), version 3.0, April 30, 1996.
DOD, A Framework for Evolution of the Department of Defense Intelligence Information System (DODIIS), July 1991.
Technical Standards for Command and Control Information Systems (CCISs) and Information Technology" by the Army Tactical Command and Control Information System Permanent Working Group, SHAPE, Belgium, Edition 4, 25 February 1994.
Office of Management and Budget (OMB), Federal Participation in the Development and Use of Voluntary Standards, Circular A-119, Revised October 20, 1993.
2.4.2 Non-government publications. The following documents form a part of this document to the extent specified herein. Unless otherwise specified, the issues of the documents adopted by the DOD are listed in the latest issue of the DODISS. Unless otherwise specified, the issues of documents not listed in the DODISS are the issues of the documents cited herein.
IEEE Std 1003.0-1995, Guide to the POSIX Open System Environment (OSE), May 1995.
2.4.3 Standards availability. Unless otherwise indicated, copies of federal and military specifications, standards, and handbooks are available to DOD activities and their contractors from the Commanding Officer, Naval Publications and Forms Center, (ATTN: NPODS), 5801 Tabor Avenue, Philadelphia, PA, 19120-5099. Others must request copies of FIPS from the National Technical Information Service, 5285 Port Royal Road, Springfield, VA, 22161-2171. Non-government standards and other publications are normally available from the organizations that prepare or distribute the documents (see section 2.3). These documents also may be available in or through libraries or other informational services.
18.104.22.168 International Organization for Standardization (ISO) standards. In the United States, ISO standards can be obtained from the American National Standards Institute (ANSI, see below), which is the official United States representative to ISO. ISO standards are also available directly from the ISO office:
1 Rue de Varembe
Case Postale 56
CH-1211, Geneve 20 Switzerland/Suisse
22.214.171.124 ANSI standards. ANSI standards are available from the American National Standards Institute at:
11 West 42nd Street
New York, NY 10036
(212) 642-4900 (telephone)
(212) 398-0023 (fax)
(212) 302-1246 (sales fax)
126.96.36.199 Institute of Electrical and Electronics Engineers (IEEE) standards. IEEE standards are available from the IEEE Standards Board:
445 Hoes Lane
Piscataway, NJ 08855-1331
188.8.131.52 Government standards. MIL standards are available from local publications offices. National Institute of Standards and Technology (NIST) publications are sold by the Government Printing Office (GPO) and by the National Technical Information Service (NTIS). Order numbers for National Bureau of Standards (NBS)/NIST series numbers, technical notes, or special publications may be obtained from NIST Publications and Program Inquiries at:
Gaithersburg, MD 20899
Documents then may be ordered by order number from the GPO at:
Superintendent of Documents
U.S. Government Printing Office
Washington, D.C. 20402
Federal Information Processing Standards, NBS/NIST Interagency Reports, and Grant/Contract Reports are available only from:
National Technical Information Service (NTIS)
5285 Port Royal Road
Springfield, VA 22161
(703) 487-4650 information
(800) 336-4700 orders
184.108.40.206 International Telecommunication Union (ITU) Telecommunications Standardization Sector (TSS) standards. Formerly the International Telegraph and Telephone Consultative Committee (CCITT), ITU-TSS documents can be obtained from:
ITU-TSS General Secretariat
International Telecommunications Union
Place des Nations, Ch-1211
Geneve 20, Switzerland/Suisse
41 22 730 5111 (telephone)
41 22 733 7256 (fax)
2.4.4 Order of precedence. In general, order of precedence for DOD applications is JTA Mandated followed by JTA Adopted standards. Nothing in this document supersedes applicable laws and regulations unless a specific exemption has been obtained.
2.5. Information Technology Standards Guidance Reference Model
2.5.1 Reference Model.
220.127.116.11 Introduction. This section of Part 1 of the ITSG describes a high-level model for the ITSG that will reduce duplication and assist in coordination. It includes discussion of the overall organization of the ITSG as well as the organization of information internal to a base service area (BSA).
18.104.22.168 Problem. As the Adopted Information Technology Standards (AITS) and ITSG expand beyond the limited areas covered by the original National Institute of Standards and Technology (NIST) Application Portability Profile (APP) and Technical Architecture Framework for Information Management (TAFIM), a growing number of BSA's appear not to fit into a specific area. For example, is Distributed Database a Data Management or Distributed Computing service area? Is Raster Graphics a Data Interchange or Graphics service area? These situations can lead to duplication and the potential for inconsistent guidance. The proliferation of additional overlapping service areas, such as multimedia, visual information, modeling and simulation, or document management will expand the problem. Defense Information Systems Agency (DISA) subject matter experts (SMEs) are responsible for coordinating their recommendations with other related SMEs, but they have a difficult time knowing where coordination is required without global knowledge of all areas. This ITSG model will help reduce duplication and eliminate inconsistency, with little disruption to the existing ITSG and AITS documents.
22.214.171.124 Current ITSG Model. Historically the ITSG has used the Department of Defense (DOD) Technical Reference Model (TRM) shown in Figure 2.5-1 as the base model. The ITSG uses the TRM platform service areas as Major Service Areas, each of which is divided into several Mid-Level Service Areas and ultimately into many BSAs. These service areas are used to classify standards for application programming interfaces (APIs) and external environment interfaces (EEIs). The ITSG also includes standards that do not match either of these definitions (e.g., procedural standards). Several organizations have extended the DOD TRM to handle standards such as hardware and media that are not represented well in the current TRM. Discussions are continuing on how to represent the "horizontal" cross-area services such as security and distributed computing. Additional ITSG volumes have been proposed for areas such as data compression. Before defining additional volumes, the underlying model should be reconsidered to ensure that the ITSG volumes will provide understandable consistent guidance.
FIGURE 2.5-1 DoD Technical Reference Model
126.96.36.199 ITSG Model. The ITSG model is discussed at two levels: global and local. The global level discusses the parts of the ITSG, while the local level discusses the organization internal to a base service area. At the global level, two types of volumes exist, as illustrated by Table 2.5-1, which is described below. The ITSG has seven major service area volumes, one for each of the TRM major service areas, as shown by the vertical boxes at the top of Table 2.5-1. These service areas closely correspond to the service areas from the NIST APP and the Institute of Electrical and Electronics Engineers (IEEE) POSIX.0 open systems reference model, as shown in Table 2.5-2 which describes the major service areas. All other volumes represent cross-area services and are composed of BSAs copied from the major service area volumes. These are illustrated by horizontal boxes in Table 2.5-1. Within Table 2.5-1, the entries BSAxx represent BSAs to show their usage across volumes. Table 2.5-1 is for illustrative purposes only and does not map to any particular BSA.
TABLE 2.5-1 Sample Global view of ITSG Model
Major Service Areas
Software Engineering Services
User Interface Services
Data Management Services
Notes: 1. BSAs marked with a prime (') are a "clone" of a foundation BSA.
2. Not a comprehensive list of cross-area services.
1. BSAs marked with a prime (') are a "clone" of a foundation BSA.
2. Not a comprehensive list of cross-area services.
188.8.131.52.1 Foundation BSA. Each BSA will be uniquely "grounded" in one ITSG major service area. This BSA is referred to as the "foundation BSA." The foundation BSA may be "cloned" in other volumes in a controlled manner, but the discussion and recommendations must be the same in each area. A clone will consist of a textual copy of the foundation BSA material to make the ITSG volumes easier to use. The configuration management procedures will ensure that the copies remain consistent. The SME for the foundation BSA is responsible for coordination with the SME for each area in which the BSA is used. A BSA may be cloned in another major service area volume if a BSA is appropriate in multiple areas. The Raster Graphics BSA mentioned earlier (illustrated by BSA51) and language bindings (illustrated by BSA31 and BSA51) are examples of areas in which this is desirable. The major service areas are defined below to minimize this duplication.
184.108.40.206.2 Spanning Service Areas. Spanning service area volumes are constructed for any subject domain that crosses major service areas. The classic examples are system management and security services, but numerous others have been proposed. Spanning service areas are composed entirely of cloned BSAs, as illustrated in Table 2.5-1. If the spanning service area requires a BSA that is not in a major service area volume, then the BSA must be added to an appropriate major service area. The spanning area volume can include introductory material that is specific to the area. All BSAs that relate to the cross-area subject are copied into the volume. For example in Table 2.5-1, BSA32, BSA43, BSA73, and BSA83 relate to security. The clone BSA will contain the same recommendation as the foundation BSA. The spanning service area SME is responsible for coordinating with the foundation BSA's SME for each BSA; the foundation SME is responsible for coordinating with all other SMEs using the foundation BSA. The configuration management process, discussed in a separate document, will be used to resolve any conflicts.
2.5.2 ITSG Major Service Areas. The major service areas, defined to reduce overlap, are listed below.
220.127.116.11 Software Engineering Services. Services that provide the infrastructure used to develop and maintain software, including general purpose computer languages. Does not include languages specific to another service area, such as user interface definition languages or data retrieval languages (e.g., SQL). Does not include language bindings, which are included with the service being supplied by the binding; however, these may be cloned here.
18.104.22.168 User Interface Services. Defines methods by which humans interact with applications, regardless of media (e.g., audio, video). Excludes media-independent formats for the exchange of multimedia objects (e.g., graphics file formats), which are included under Data Interchange, but may be cloned here.
22.214.171.124 Data Management Services. Services related to the management of data independent of a specific application, including data creation, storage, sharing, retrieval, and manipulation, in a single-host or distributed environment. Includes languages and protocols for the manipulation of multi-media objects, as well as all formats and protocols required to extend these services into a distributed environment, and relevant management and security services.
126.96.36.199 Data Interchange Services. Services related to the exchange of information, including the format and semantics of exchange between applications on the same or different platforms. Includes formats for the storage and exchange of multimedia objects, which may be cloned under User Interface or Graphics Services. Does not include communications protocols at OSI layer 6 and below.
188.8.131.52 Graphics Services. Services related to the creation and manipulation of displayed images. Excludes media-independent formats for the exchange of multimedia objects (e.g., graphics file formats), which are included under Data Interchange, but may be cloned here.
184.108.40.206 Communications and Network Services. Services required for data transport without regard for the type of information. Basically includes the services and protocols for OSI layers 6 and below, plus foundation layer 7 services (directory services, mail, file transfer, remote login). All other application layer services and protocols will be included elsewhere. Includes security services related to these base services.
220.127.116.11 Operating System Services. Core services needed to operate and administer the application platform and provide an interface between the applications and the hardware platform. Services related to process management, tasking, memory allocation, and basic file handling. It also includes system-wide management services, such as accounting and user/group management that do not fit under any other service areas. It includes all formats and protocols required to extend these core services into a distributed environment, as well as relevant security services.
Table 2.5-2 relates the ITSG major service areas to service areas defined in the NIST Application Portability Profile and the IEEE Open Systems Reference Model (POSIX.0).
TABLE 2.5-2 ITSG Major Service Areas Related to NIST APP and IEEE OSE/RM
Major Service Area
OSE Reference Model
Software Engineering Services
Software Engineering Services
Operating System Services
Operating System Services
User Interface Services
Human/Computer Interface Services
Human/Computer Interaction Services
Data Management Services
Data Management Services
Data Interchange Services
Data Interchange Services
Communications and Network Services
Communications and Network Services
2.5.3 Proposed Rules. The following rules are proposed for the ITSG reference mode:
(1) The ITSG has two types of volumes. There are seven major service area volumes, and additional (six in version 3.1) spanning service area volumes.
(2) The ITSG Major Service Areas are Software Engineering Services, User Interface Services, Data Management Services, Data Interchange Services, Graphics Services, Communications and Network Services, and Operating System Services.
(3) Each BSA will be uniquely "grounded" in one ITSG major service area. The BSA will be grounded in a "foundation BSA." The BSA may be "cloned" by reference or by copying the text, although the latter is preferred.
(4) Cloned BSAs may appear in more than one major service area volume.
(5) Spanning service area volumes are composed entirely of cloned BSAs. If the spanning service area requires a BSA that is not in a major service area volume, then the BSA must be added to an appropriate major service area. The six spanning service areas, as of version 3.1) are System Management, Security, Distributed Computing, Multimedia, Human Factors, and Internationalization.
(6) The cloned BSA will contain the same recommendation as the foundation BSA.
(7) The SME for the foundation BSA is responsible for coordination with the SME for each area in which the BSA is used.
(8) The cross-area volume SME is responsible for coordinating with the foundation BSA SME for each BSA.
(9) The configuration management process will be used to resolve any conflicts.
2.6.1 Acronyms used in the ITSG. The acronyms used in the ITSG are defined as follows:
AAP Association of American Publishers
ACGIH American Conference of Government Industrial Hygienists
ACL Access Control List
ACM Association for Computing Machinery
ACP Allied Communication Publication
ACP Association Control Protocol
ACSE Association Control Service Element
ACVC Ada Compiler Validation Capability
AD Addendum (ISO)
AdaIC Ada Information Clearinghouse
ADMAPS Automated Document Management and Publishing System
ADP Automated Data Processing
ADS Automated Data Systems
ADSIA Allied Data Systems Interoperability Agency (NATO)
AECMA Association European des Constructeurs de Material Aerospatial
AEP Application Environment Profile
AES Application Environment Specification
AFCEA Armed Forces Communications and Electronics Association
AFS Andrew File System (CMU)
AIAA American Institute of Aeronautics and Astronautics
AIE Ada Integrated Environment (USAF)
AIS Automated Information Systems
AIIM Association for Information and Image Management
AIM Automatic Identification Manufacturers
AITS Adopted Information Technology Standards
AJPO Ada Joint Program Office (DOD)
ALE Automatic Link Establishment
ALS Ada Language System (U.S. Army)
AM Amendment (ISO)
ANS American Nuclear Society
ANSI American National Standards Institute
API Application Program Interface
APP Application Portability Profile (NIST)
APSE Ada Programming Support Environment
ARIDPCM Adaptive Recursive Interpolative Differential Pulse Code Modulation
ARCAS Army Reserve Component Automation System
ASC Accredited Standards Committee (ANSI)
ASCII American National Code for Information Interchange
ASIS Ada Semantic Interface Specification
ASME American Society of Mechanical Engineers
ASN Abstract Syntax Notation
ASR Ada Software Repository
ASTM American Society for Testing and Materials
ATA Air Transport Association of America
ATCCIS Army Tactical Command and Control Information System
ATIS A Tool Integration Standard
ATM Automated Teller Machine
ATMI Application to Transaction Manager Interface
AV-I Audio Video - Interleave
BDF Bitmap Distribution Format
BER Basic Encoding Rules (ASN)
BMP Windows Bitmap Format (Microsoft)
BOM Bit-Oriented Messages
BSA Base Service Area
BSD Berkeley Software Distribution
BSFT Byte Stream File Transfer
BSI British Standards Institute (UK)
CAD Computer-Aided Design
CAE Common Application Environment
CAIS Common Ada Programming Support Environment (APSE) Interface Set
CALS Computer-Aided Acquisition and Logistic Support
CAM Computer-Aided Manufacturing
CASE Computer Aided Software Engineering
CBEMA Computer and Business Equipment Manufacturers Association
C3I Command, Control, Communications, and Intelligence
CCD Charge Coupled Devices
CCIS Command and Control Information System
CCITT Comite Consultatif International de Telegraphique et Telephonique (International Telegraph and Telephone Consultative Committee) (now called the ITU-TSS)
CCR Commitment, Concurrency, and Recovery
CCS Continuous Composite Servo
CCTA Central Computer and Telecommunication Agency (UK)
CD Committee Draft (ISO)
CD Compact Disc
CD-I Compact Disc - Interactive
CD-R Compact Disc - Recordable
CD-ROM Compact Disc - Read Only Memory
CD-V Compact Disc - Video
CD-WO Compact Disc - Write Once
CD-XA Compact Disc - Extended Architecture
CDIF CASE Data Interchange Format
CECOM Communications-Electronics Command (U.S. Army)
CEDD Committee for the Exchange of Digital Data (IHO)
CFS Center for Standards (DISA/JIEO)
CGI Computer Graphics Interface
CGM Computer Graphics Metafile
CIA Central Intelligence Agency
CID Commercial Item Description
CIE Comite International de l'Eclairage (International Commission on Illumination)
CIM Center for Information Management (DISA)
CINC Commander in Chief
CIS CASE Integration Services
CJCS Chairman of the Joint Chiefs of Staff
CLNS Common LISP Object System
CM Communication Manager
CMA Consolidated Management Architecture
CM-API Consolidated Management API
CMIP Common Management Information Protocol
CMIS Common Management Information Services
CMOT CMIP Over TCP/IP
CMU Carnegie Mellon University
CMW Compartmented Mode Workstation
CMYK Cyan, Magenta, Yellow, and Black
COE Common Operating Environment
COEWG Common Operating Environment Working Group
COMPUSEC Computer Security
CONS Connection Oriented Network Service
CORBA Common Object Management Request Broker Architecture
COTS Commercial Off-the-Shelf
CPC Consortia Public Consensus
CPC Cross-Platform Communications (IMA)
CPSC Consumer Product Safety Commission
CRSS C3I Reusable Software System
csh C Shell
CTE Compound Text Encoding
CUA Common User Access
DAC Discretionary Access Controls
DAD Draft Addendum (ISO)
DAM Draft Amendment (ISO)
DAP Document Application Profile
DARPA Defense Advanced Research Program Agency
DBF Discrete Block Format
DBMS Database Management System
DBSSF Database System Study Group
DCA Document Content Architecture
DCE Distributed Computing Environment
DCPS Data Communications Protocol Standards
DCW Digital Chart of the World (DMA)
DDE Dynamic Data Exchange
DDES Digital Data Exchange Specification
DDF Data Descriptive File (for Information Interchange)
DDRS Data Dictionary/Repository System
DEA Data Encryption Algorithm
DEC Digital Equipment Corporation
DER Distinguished Encoding Rules (BER/ASN)
DES Data Encryption Standard
DFR Document File and Retrieval
DFS Distributed File System
DGIWG Digital Geographic Information Working Group
DIA Defense Intelligence Agency
DIA Display Industry Association
DIA Document Interchange Architecture
DIB Directory Information Base
DID Data Item Description
DIF Data Interchange Format
DIGEST Digital Geographic Information Exchange Standard
DIS Draft International Standard (ISO)
DISA Defense Information Systems Agency (DOD)
DFR Document Filing and Retrieval
DFS Distributed File System
DMA Defense Mapping Agency (DOD)
DME Distributed Management Environment
DMI Definition of Management Information
DNI Detailed Network Interface
DNS Domain Naming Service
DOAM Distributed Office Applications Model
DOD Department of Defense
DODIIS DOD Intelligence Information System
DODISS DOD Index of Specifications and Standards
DOS Disk Operating System
DOT Department of Transportation
DP Draft Proposed Standard (ANSI, ISO)
DPA Document Printing Application
DPS Digital Production System (DMA)
DSRS Defense Software Repository System
DSS Digital Signature Standard
DSSC Distributed Systems Steering Committee (IEEE)
DSSSL Document Style Segmentation and Specification Language
DTAM Document Transfer and Manipulation
DTMP DCPS Technical Management Panel
DTP Distributed Transaction Processing
DVI Digital Video Interactive
DWM Desqview Window Manager
DXF Drawing Exchange Format (Autodesk)
EAN International Article Numbering Association
ECMA European Computer Manufacturers' Association
EDI Electronic Document Interchange
EDIF Electronic Data Interchange Format
EDIFACT EDI for Administration, Commerce, and Transport
EEC European Economic Community
EEI External Environment Interface
EIA Electronic Industries Association
EMPM Electronic Manuscript Preparation and Markup
EPA Environmental Protection Agency
EPHOS European Procurement Handbook for Open Systems
ES-IS End System to Intermediate System
EWOS European Workshop for Open Systems
FAA Federal Aviation Administration
FAP Formats and Protocols (SQL)
FDDI Fiber Distributed Data Interface
4GL Fourth Generation Language
FIMS Form Interface Management System
FIPS Federal Information Processing Standard (NIST)
FIPS PUB Federal Information Processing Standard Publication
FM Field Manual
FTAM File Transfer, Access, and Management
FTP File Transfer Protocol (Internet)
FY Fiscal Year
GDMO Guidelines for the Definition of Managed Objects
GDSII Graphic Design System II
GIF Graphics Interchange Format
GIS Geographic Information System
GKS Graphical Kernel System
GKS-3D Graphical Kernel System for Three Dimensions
GMI Generic Management Information
GNMP Government Network Management Profile
GOSIP Government Open Systems Interconnection Profile
GOTS Government Off-the-Shelf
GPC Government Public Consensus
GPC Graphics Performance Characterization Committee
GPEF Generic Package of Elementary Functions
GPO Government Printing Office
GPPF Generic Package of Primitive Functions
GRACE Generic Reusable Ada Components for Engineering
GUI Graphical User Interface
GULS Generic Upper Layer Security
HCI Human-Computer Interface
HDL Hardware Description Language
HDLC High-Level Data Link Control
HDTV High Definition Television
HF High Frequency
HFS Human Factors Society
HLHSR Hidden Line/Hidden Surface Removal
HOL High Order Language
HP Hewlett Packard
HPDL Hewlett-Packard Page Description Language
HYTIME Hypermedia/Time-based Structuring Language
IAB Internet Architecture Board
IBM International Business Machines Corporation
ICAM Integrated Computer-Aided Manufacturing
ICASE Integrated Computer-Aided Software Engineering
ICC International Color Consortium
ICCCM Interclient Communications Conventions Manual
ICCD Integrated Charge Coupled Devices
ICR Intelligent Character Recognition
IDEF Integrated Definition
IDEF ICAM Definition Language
IDHS Intelligence Data Handling System
IDL Interface Definition Language
IDT Interactive Design Tools
IDTIF Interactive Design Tool Interchange Format
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
I4DL Interface, Inheritance, Implementation, and Instantiation Definition Language
IFF Interchange File Format
IGES Initial Graphics Exchange Specification
IHO International Hydrographic Organization
IM Information Management
IMA Interactive Multimedia Association
IMA International MIDI Association
IOH Integrated Open Hypermedia
IP Information Processing
IPC International Public Consensus
IPC Interprocess Communications
IPO IGES/PDES Organization
IPSC Information Processing Standards for Computers
IR Interim Report
IRDS Information Resource Dictionary System
IS International Standard (ISO)
ISAM Indexed Sequential Access Method
ISDN Integrated Services Digital Network
ISEE Integrated Software Engineering Environment
IS-IS Intermediate System to Intermediate System
ISO International Organization for Standardization
IT Information Technology
ITPB Information Technology Policy Board (DOD)
ITSEC Information Technology Security Evaluation Criteria
ITSG Information Technology Standards Guidance
ITU International Telecommunications Union
ITU-R International Telecommunications Union - Radiography (formerly the CCIR)
ITU-TSS International Telecommunications Union - Telecommunications Standardization Sector (formerly the CCITT)
JBIG Joint Bi-Level Imaging Group
JCALS Joint Computer-Aided Acquisition and Logistic Support
JIEO Joint Interoperability Engineering Organization
JPEG Joint Photographic Experts Group
JTA Joint Technical Architecture
JTC1 Joint Technical Committee One (ISO/IEC)
KBPS Kilobytes per Second
KMP Key Management Protocol
LAN Local Area Network
LM License Management
LMS Logistics Management System
LS License Management System
LSA Logistic Support Analysis
LSAR Logistic Support Analysis Records
LWER Light Weight Encoding Rules (BER/ASN)
LZW Lempel-Ziv-Welsh (data compression algorithm)
MAC Mandatory Access Controls
MAC Media Access Control
MAC Message Authentication Code
MAP Manufacturing Automation Protocol
MCCR Mission Critical Computer Resources
MHEG Multimedia/Hypermedia Experts Group
MHS Message Handling System
MIB Management Information Base
MICR Magnetic Ink Character Recognition
MIDI Musical Instrument Digital Interface
MIL-STD Military Standard
MIS Management Information System
MIT Massachusetts Institute of Technology
MMFS Manufacturing Message Format Standard
MMI Man-Machine Interface
MMS Manufacturing Message Standard
MO:DCA Mixed Object Document Content Architecture (IBM)
MOOLIT Motif/Open Look Toolkit Intrinsics
MOTIS Message Oriented Text Interchange System
MOSS Map Overlay Statistical System (Autometric)
MPC Multimedia Personal Computer
MPEG Motion Pictures Expert Group
MSP Message Security Protocol
MTA Message Transfer Agent
MTF Message Text Formats
MTF Message Transfer Facility
MUI Management User Interface
MVL Multivalue Logic System
MWM Motif Window Manager
NAPLPS North American Presentation Level Protocol Syntax
NASA National Aeronautics and Space Administration
NATO North Atlantic Treaty Organization
NBS National Bureau of Standards (now NIST)
NBSIR NBS Interim Report
NCGA National Computer Graphics Association
NCSC National Computer Security Center
NCSL National Computer Systems Laboratory (NIST)
NDL Network Data Language
NeL Network Event Logger
NetLS Network License System
NFS Network File System
NGCR Next Generation Computer Resources
NGS Non-Government Standards
NGSB Non-Government Standards Body
NIMA National Imagery and Mapping Agency (formerly DMA)
NISO National Information Standards Organization
NIST National Institute of Standards and Technology
NISTIR NIST Interim Report
NITF National Imagery Transmission Format
NITFS National Imagery Transmission Format Standard
NIUF National ISDN Users' Forum
NIUG National IGES User's Group
NLSP Network Layer Security Protocol
NMF Network Management Forum
NMSIG Network Management SIG
NPC National Public Consensus
NPESA National Printing Equipment and Supply Association
NSA National Security Agency
NSC National Safety Council
NSEP National Security Emergency Preparedness
NSI Non-Standard Interface
NT New Technology (MS-Windows)
NTF National Transfer Format (BSI)
NTIS National Technical Information Service
NTSC National Television System Committee (US)
OCR Optical Character Recognition
OCR-MA Optical Character Recognition- Matrix
ODA Office Document Architecture
ODIF Office Document Interchange Format
ODL Office Document Language
ODMG Open Database Management Group
ODP Open Distributed Processing
ODT Optical Digital Technologies
OIM Object Information Management
OIW OSE Implementors' Workshop (NIST)
OLE Object Linking and Embedding
OLIT Open Look Intrinsics Toolkit
OLTP Online Transaction Processing
OLWM Open Look Window Manager
OMG Object Management Group
ONC Open Network Computing
OSD Office of the Secretary of Defense
OSE Open System Environment
OSF Open Software Foundation
OSHA Office of Safety and Health Administration
OSI Open Systems Interconnection (ISO)
PAL Phase Alternation Line
PAR Project Authorization Request (IEEE)
PART POSIX/Ada Real-Time project
PBX Private Branch Exchange
PC Personal Computer
PCF Portable Compiled Format
PCIS Portable Common Interface Set (NATO)
PCMCIA Personal Computer Memory Card Industry Association
PC/NFS Personal Computer/Network File System
PCTE Portable Common Tools Environment (ECMA)
PDAD Preliminary Draft Addendum (ISO)
PDAM Preliminary Draft Amendment (ISO)
PDDI Product Data Definition Interface
PDES Product Data Exchange Using STEP
PDI Picture Description Language
PDL Page Description Language
PEL Picture Element
PER Packed Encoding Rules (BER/ASN)
PERMS Personnel Electronic Records Management
PEX PHIGS Extension to X
PHIGS Programmer's Hierarchical Interactive Graphics System
PHIGS+ Programmer's Hierarchical Interactive Graphics System Plus Lumier and Surfaces (PLUS)
PICS Protocol Implementation Conformance Statement
PIF Page Image Format
PIK Programmer's Imaging Kernel
PLPS Presentation Level Protocol Syntax
PLUS Plus Lumier und Surfaces (see PHIGS)
PM Program Manager
POSIX Portable Operating System Interface for Computer Environments
PRC Planning Research Corporation
RAPID Reusable Ada Products for Information Systems Development
RDA Remote Database Access
RFC Request for Comment
RFP Request for Proposal
RFS Remote File System
RGB Red, Green, Blue
RLE Run Length Encoding
RODE Remote Open Document Editing
ROP Remote Operations Protocol
ROSE Remote Operations Service Elements
ROSEP Remote Operations Service Elements Protocol Definition
ROSES Remote Operations Service Elements Service Definition
RPC Remote Procedure Call
RRIP Rock Ridge Interchange Protocol
RTCP Real-Time Communication Protocols
RTSE Reliable Transfer Service Element
SAA Systems Application Architecture
SAE Society of Automotive Engineers
SAG SQL Access Group
SAME SQL Ada Module Extensions
SAMEDL SAME Description Language
SBIS Sustaining Base Information System
SCCS Source Code Control System
SCD Stock Control and Distribution (SYSTEM)
SCO Santa Cruz Operation
SDD Software Design Document
SDF Standard Delay File Format
SDIF SGML Document Interchange Format
SDNS Secure Data Network Systems
SDO Standards Developing Organization
SDTS Spatial Data Transfer Standard
SDU Software Development Utilities
SECAM Systeme Electonique Couleur Avec Memoire
SEE System Engineering Environment
SEI Software Engineering Institute
SE-ODP Support Environment for Open Distributed Processing
SGML Standard Generalized Markup Language
SIF Standard Interchange Format (Intergraph)
SIG Special Interest Group
SIGADA Ada Special Interest Group (ACM)
SIGGRAPH Graphics Special Interest Group (ACM)
SII System Internal Interface
SILS Standard for Interoperable LAN Security
SMDL Standard Music Description Language
SMB Server Message Block
SMD Standardized Military Drawing
SME Society of Manufacturing Engineers
SME Subject Matter Expert
SMI Structure of Management Information
SMIGS Standard Military Graphics Symbols
SMP Simple Management Protocol
SMPTE Society of Motion Picture and Television Engineers
SMTP Simple Mail Transfer Protocol
SNA Systems Network Architecture
SNDCF Subnetwork Dependent Convergence Facility
SNF Server Normal Format
SNI Simple Network Interface
SNMP Simple Network Management Protocol
SP Security Protocol
SP Special Publication (NIST)
SP Standardization Profile
SPC Software Productivity Consortium
SPDL Standard Page Description Language
SPI System Programming Interface
SPM Software Programmer's Manual
SQL Structured Query Language
SS Sampled Servo
SSC Standards Systems Center
STANAG Standardization Agreement (NATO)
STARS Software Technology for Adaptable, Reliable Systems
STDL Standardized Transaction Definition Language
STL Standard Textual Language
STEP Standard for Exchange of Product Model Data
SUSP System Use Sharing Protocol
SVID System V Interface Definition
SVRn System V Release n (USL)
TACO-2 Tactical Communication Protocol 2
TADIL Tactical Digital Information Link
TAE Transportable Application Environment
TAE+ Transportable Application Environment Plus
TAR UNIX Transfer Tape Format
TBD To Be Determined
TCL TAE Command Language
TCOS Technical Committee on Operating Systems (IEEE)
TCP/IP Transmission Control Protocol/Internet Protocol
TCSEC Trusted Computer Systems Evaluation Criteria
TDI Trusted Database Interpretation
TEI Text Encoding Initiative
TFA Transparent File Access
TFTP Trivial File Transfer Protocol
TGA Targa Image Format
TIFF Tagged Image File Format
TIGER Topographically Integrated Geographical Encoding and Referencing (U.S. Census Bureau)
TLI Transport Layer Interface
TLSP Transport Layer Security Protocol
TNI Trusted Network Interpretation
TNT The News Toolkit
TOP Technical and Office Protocol
TOSCA Text and Office Systems Color Architecture (ISO)
TP Transaction Processing
TR Technical Report
TRIF Tiled Raster Interchange Format (DOD)
TS Timer Services
TSR Terminate and Stay Resident
TSS Telecommunications Standardization Sector (ITU)
UCC Uniform Code Council
UDT Unstructured Data Transfer
UEF User Exchange Format
UFS Unix File System
UI Unix International
UIDL User Interface Definition Language
UIL User Interface Language (OSF)
UIMS User Interface Management Services
UISRM User Interface System Reference Model (NIST)
UK United Kingdom
UPC Uniform Product Code
USGS United States Geological Survey
USL Unix Systems Labs
USMTF United States Message Text Format
USS Uniform Symbology Specification
UUCP Unix-to-Unix Copy Protocol
VDI Virtual Device Interface
VDM Virtual Device Metafile
VDT Video Display Terminal
VHDL VHSIC Hardware Description Language
VMF Variable Message Format
VMUIF Voice Messaging User Interface Forum
VOXEL Volume Element
VPF Vector Product Format
VPS Vector Product Standard
VQ Vector Quantization
VT Virtual Terminal
WAN Wide-Area Network
WD Working Draft (ISO)
WDAD Working Draft Addendum (ISO)
WDAM Working Draft Amendment (ISO)
WG Working Group
WMO World Meterological Organization
WORM Write-Once Read Many
WWMCCS World-Wide Military Command and Control System
WYSIWYG What You See Is What You Get
XAPIA X.400 API Association
XAP-TP X/Open API- Transaction Processing
XCDR X/Open CD ROM
XDR External Data Representation
XDS X/Open Directory Services
XDSF X/Open Distributed Security Framework
X11Rn X Windows version 11, Release n
XLFD X Logical Font Description
XMOG X/Open Managed Object Guide
XMP X/Open Management Protocol
XMPP X/Open Management Protocol Profiles
XNFS X/Open Network File System
XOM X/Open OSI Abstract Data Manipulation
XPG X/Open Portability Guide
XTI Transport Independent Interface
XVT Extensible Virtual Toolkit
2.6.2 Terms used in the ITSG. The following definitions align as closely as possible to the standard IEEE Computer Society definitions and come from a myriad of standards bodies. Be careful to understand the terms commonly used inside and outside this document. Different standards bodies often use different words for the same meaning or may use the same word with an assumption of a slightly different meaning. For example, the American National Standards Institute (ANSI) used the term "levels" (meaning "level 1," "level 2," and "Core") to signal a particular implementation's varying conformance level; however, this usage is parallel to the IEEE POSIX's usage of "fully conforming" and "conforming with extensions."
Abstraction: An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects, providing crisply defined conceptual boundaries, relative to the perspective of the viewer. (See Object-Based and Object-Oriented Language).
Accredited Standards Development Organization: An organization recognized as a standards development organization by ISO, IEC, ITU-T, or recognized as a standards development organization by one of the member bodies of one of these three organizations.
Adopted: The DOD status "Adopted" is used to mean that the standard in the ITSG is approved by DOD for use in satisfying each function of the BSA where there exists no JTA mandated standard. Adopted standards may be implemented but shall not be used in lieu of a mandated standard. The word adopted refers to standards included in the TAFIM.
Application: "The use of capabilities provided by an information system specific to the satisfaction of a set of user requirements." (IEEE Std 1003.0-1995)
Application Environment Profile (AEP): "A profile, specifying a completed and coherent specification of the Open System Environment (OSE), in which the standards, options, and parameters chosen are necessary to support a class of applications." (IEEE Std 1003.0-1995)
Application Platform: "A set of resources, including hardware and software, that support the services on which application software will run. The application platform provides services at its interfaces that, as much as possible, make the specific characteristics of the platform transparent to the application software." (IEEE Std 1003.0-1995)
Application Program Interface (API): "The interface between the application software and the application platform, across which all services are provided." (IEEE Std 1003.0-1995)
Application Software: "Software that is specific to an application and is composed of programs, data, and documentation (IEEE Std 1003.0-1995)
Approved: The specification has been approved and published by its sponsoring body.
Base Service Areas (BSAs): define functionality within the OSE. They also serve as logical placeholder for groupings of standards that share similar attributes of functionality. Each BSA contains a definition, approximated to the collection of standards contained within it. Each BSA parallels an industry accepted information technology "functional" area at a broad system service level. BSA definitions serve to map functional system support software requirements to specific standards through matching the BSA definition to the standards within. BSA definitions are tailored for human comprehension, not to meet a requirement for technical formalism of the OSE.
Base Standard: "An approved international standard, technical report, ITU-T Recommendation, or national standard." (IEEE Std 1003.0-1995)
Base Standard Profile: A profile, or listing, of applicable base standards. (See Profile of Standards.)
Class: A set of objects with a common structure and behavior.
Communication Interface: "That part of the API devoted to communications with other application software, external data transport facilities, and devices." (IEEE Std 1003.0-1995)
Component Profile: "A profile that is made up of a formally defined subset of a single standard." (IEEE Std 1003.0-1995)
Conditional feature: A feature or behavior referred to in a standard not essential on all conforming implementations.
Conformance: "A statement of conformance to a POSIX standard is based on a completed test of the target system using POSIX.3 conforming test methods, where for each POSIX.3 assertion for that standard, there is a correctly assigned test result code." (IEEE Std 1003.3-1991)
Conformance Documentation: "A formal record of the testing of a product for conformance to a particular standard." (ISO/IEC 9945-1)
Consortia (Standards): Standards developed by industry associations, consortia, and other public bodies not recognized as formal standards bodies.
Criteria for Inclusion: Qualities considered to determine whether a standard will be included.
Cross-Category Services: "A set of tools and/or features that has a direct effect on the operation of one or more components of the OSE, but is not in and of itself a stand-alone component." (IEEE Std 1003.0-1995)
De facto: Indicating the use of the product or specification in reality that is tantamount to being legally constituted as a standard.
De jure: Indicating that a specification has undergone the standardization process of a formal standards body.
Deficiency: A functionality needed, but not provided, by the standard.
Dependency: One standard requiring the support of other standards to create a valid implementation.
Detailed Profile: see Standard Profile.
Distributed (System, Processing): A system or process consisting of interdependent software or hardware/software entities separated either physically or chronologically.
Emerging Standard: According to the JTA, a DOD "Emerging" status denotes a candidate standard to be added as, or to replace, a mandated standard. This includes standards required to capitalize on new technologies. These candidates will help the program manager determine those areas that are likely to change in the near term (within three years) and suggest those areas in which "upgradability" should be a concern. The expectation is that emerging standards will be elevated to mandated status in the JTA when implementations of the standards mature. Emerging standards may be implemented but shall not be used in lieu of a mandated standard.
Encapsulation: The process of hiding all of the details of an object that do not contribute to its essential characteristics. (See Object-Based and Object-Oriented Language).
Explicit Services: "Services that can be accessed from an application program (via an API) and generally are only provided when requested." (IEEE Std 1003.0-1995)
External Environment: "A set of entities external to the application platform with which services are provided. External entities include people, exchangeable media that is not mounted in the platform, communication wiring, and other platforms." (IEEE Std 1003.0-1995).
External Environment Interface (EEI): "The interface between the application platform and the external environment across which services are provided. The EEI is defined primarily in support of system and application interoperability. The primary services present at the EEI comprise:
a. Human/Computer Interaction Services
b. Information Services
c. Communication Services" (IEEE Std 1003.0-1995)
Extension: An addition to the core specifications of a standard.
Formal Standards Body: "Formally recognized standards bodies responsible for definition and dissemination of public standards." (IEEE Std 1003.0-1995)
Hardware: "Physical equipment used in data processing, as opposed to programs, procedures, rules, and associated documentation." (IEEE Std 1003.0-1995).
Harmonization: "The process of ensuring that profiles do not overlap or conflict." (IEEE Std 1003.0-1995).
Hierarchy: A ranking or ordering of abstractions. (See Object-Based and Object-Oriented Language).
Hostile Standard Feature: Any feature of a standard that could impede transportability or requires additional cost to transport.
Human/Computer Interface (HCI): "The boundary across which physical interaction between a human being and the application platform takes place." (IEEE Std 1003.0-1995).
Implementation Defined: "An indication that the implementation shall define and document the requirements for correct program constructs and correct data of a value or behavior." (ISO/IEC 9945-1)
Implementation Dependent: Indicates that each implementor may define that portion of the application at will.
Implicit Services: "Services that the platform provides without a direct request." (IEEE Std 1003.0-1995)
Information Technology: Technology related to computer hardware and software for the processing, storage, and transfer of information.
Informational: Informational standards include those remaining standards that fall outside the official DOD statuses of "mandated," "adopted," "emerging," and "legacy."
Interface: "A shared boundary between two functional entities. A standard specifies the services in terms of the functional characteristics and behavior observed at the interface. The standard is a contract in the sense that it documents a mutual obligation between the service user and provider and assures stable definition of that obligation." (IEEE Std 1003.0-1995)
Internationalization: "The process of designing and developing an implementation with a set of features, functions, and options intended to satisfy a variety of cultural environments." (IEEE Std 1003.0-1995)
Interoperability: "The ability of two or more systems to exchange information and to use the information that has been exchanged." (IEEE Std 1003.0-1995)
Language-Binding API specification: "A specification that documents the source code method, consistent with a specific programming language, used by an application to access services provided by an application platform." (IEEE Std 1003.0-1995)
Language-Independent Service Specification: "A specification that defines a set of required functional semantics independent of the syntax and semantics of a programming language." (IEEE Std 1003.0-1995)
Locale: "The definition of the user environment that depends on language and cultural conventions." (IEEE Std 1003.0-1995)
Loss-less Compression: A compression technique that compresses data (or an image) without losing any bits or deteriorating the resolution of an image. Compression ratios are not tremendously high in this type of compression.
Lossy Compression: A compression technique that compresses data (or an image) but loses bits in the process. The quality of the image may deteriorate; however, extremely high compression ratios may be obtained in this type of compression.
Local Adaptation: "The process of modifying a product that is specific to one culture to make it specific to another culture." (IEEE Std 1003.0-1995)
Localization: "The process of utilizing the internationalization features to adapt an internationalized product to a specific cultural environment." (IEEE Std 1003.0-1995)
Major Service Area: A major service area (MSA) is one of the basic categories of services required by information systems. The MSAs are Software Engineering, User Interface, Data Management, Data Interchange, Graphics, Communications and Network, and Operating System Services.
Mandated Standard: The DOD status "Mandated" is used for those standards mandated by the JTA. A standard is mandatory in the sense that IF a service/interface is going to be implemented, it shall be implemented in accordance with the associated standard. If a required service can be obtained by implementing more than one standard, the appropriate standard should be selected based on system requirements.
Modularity: The property of a system that has been decomposed into a set of cohesive and loosely coupled modules. (See Object-Based and Object-Oriented Language)
Object (Instance, Software Object): An object is a software entity that has state, behavior, and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable.
Object-Based Language: Any programming language that supports some but not all of the characteristics of Abstraction, Encapsulation, Modularity, and Hierarchy.
Object-Oriented Language: Any programming language that fully supports the characteristics of Abstraction, Encapsulation, Modularity, and Hierarchy.
Obsolescent: An indication that a certain feature may be considered for withdrawal in future revisions of a standard.
Open Specifications: "Specifications that are maintained by an organization that uses an open, public consensus process to accommodate new technologies and user requirements over time." (IEEE Std 1003.0-1995)
Open System: "A system that implements sufficient open specifications or standards for interfaces, services, and supporting formats to enable properly engineered applications software:
a. To be ported with minimal changes across a wide range of systems from one or more suppliers
b. To interoperate with other applications on local and remote systems
c. To interact with people in a style that facilitates user portability" (IEEE Std 1003.0-1995)
Open System Application Program Interface: "A combination of standards-based interfaces specifying a complete interface between an application program and the underlying application platform." (IEEE Std 1003.0-1995)
Open System Environment (OSE): "A comprehensive set of interfaces, services, and supporting formats, plus user aspects for interoperability or for portability of applications, data, or people, as specified by information technology standards and profiles." (IEEE Std 1003.0-1995)
Option: "A portion of the specification within a standard that is not required to be present in a conforming implementation." (See also Conditional Feature.) (IEEE Std 1003.3-1991)
Performance: "A measure of a computer system or subsystem to perform its functions; for example, response time, throughput, number of transactions per second. The efficiency of a system in accomplishing pieces of work is an attribute of performance." (IEEE Std 1003.0-1995)
Performance Requirement: "A requirement that specifies a performance characteristic that a system or system component must possess; for example, speed, accuracy, frequency." (IEEE Std 1003.0-1995)
Platform Internal Interface (PII): "The interface between application platform service components within that platform." (IEEE Std 1003.0-1995)
Platform Profile: "A profile whose focus is on functionality and interfaces for a particular type of platform, which may be a single processor shared by a group of applications or a large distributed system with each application dedicated to a single processor." (IEEE Std 1003.0-1995)
Portability (application software): "The ease with which application software and data can be transferred from one application platform to another." (IEEE Std 1003.0-1995)
POSIX (Portable Operating System Interface for Computer Environments): The term "POSIX" has been evolving into a term with a number of different meanings. POSIX is sometimes used to denote the formal standard ISO/IEC 9945-1:1990, sometimes to denote that standard plus related standards and drafts emerging from IEEE PASC working groups, and sometimes to denote the groups themselves. This guide refers to the original POSIX standard by its standard designation, ISO/IEC 9945-1:1990, and not by the term POSIX.
The IEEE groups developing standards related to IEEE P1003 are called IEEE P1003.n working groups. Examples are the IEEE working groups P1003.2 and P1003.3, etc. The names of the groups are sometimes abbreviated POSIX.2, POSIX.3, etc., but this convention is not used by this guide; confusion could result when the IEEE P1003 decimal number does not match the ISO/IEC 9945 part number (such as with P1003.7 and ISO/IEC 9945-3). Furthermore, other IEEE open systems working groups such as P1224 do not use the POSIX prefix. Therefore, all IEEE projects and working groups are referred to uniformly as Pnnnn.
The standards emerging out of the POSIX working groups are referred to by their formal names (e.g., IEEE Std. 1003.2-1992 or IEEE P1003.10/D9) and are called either POSIX Base Standards or POSIX Standardized Profiles (POSIX SPs). (IEEE Std 1003.0-1995)
POSIX Standardized Profile (POSIX SP): "A Standardized Profile that specifies the application of certain POSIX base standards in support of a class of applications and does not require any departure from the structure defined by the Reference Model for POSIX systems." (IEEE Std 1003.0-1995)
Process: "An address space and one or more threads of control that execute within that address space, and their required system resources." (IEEE Std 1003.0-1995)
Product Implementation: The usable, binary loadable code sold by vendors and, in some cases, bundled with hardware.
Profile: "A set of one or more base standards, and, where applicable, the identification of chosen classes, subsets, options, and parameters of those base standards, necessary for accomplishing a particular function." (IEEE Std 1003.0-1995)
Profile, Standard's: A listing of the specific set of options from a standard that will be implemented to satisfy a system's requirements.
Profile of Standards: A list of the standards to be applied in a given system or functional area.
Programming Language API specification: "The interface between applications and application platforms traditionally associated with programming language specifications, such as program control, math functions, string manipulation." (IEEE Std 1003.0-1995)
Proprietary Specification: A specification developed and marketed by a company having exclusive rights to modify and sell it. The specification may be changed at will by the owner without going through a standards body consensus process.
Protocol: "A set of semantic and syntactic rules that determine the behavior of entities that interact." (IEEE Std 1003.0-1995)
Public Specifications: "Specifications that are available, without restriction, to anyone for implementation, sublicensing, and distribution (i.e., sale) of that implementation." (IEEE Std 1003.0-1995)
Reference Model: "A structured collection of concepts and their relationships that scope a subject and enable the partitioning of the relationships into topics relevant to the overall subject and that can be expressed by a common means of description." (IEEE Std 1003.0-1995)
Scalability: "The ability to provide functionality up and down a graduated series of application platforms that differ in speed and capacity." (IEEE Std 1003.0-1995)
Security: "The protection of computer resources (e.g., hardware, software, and data) from accidental or malicious access, use, modification, destruction, or disclosure. Tools for the maintenance of security are focused on availability, authentication, accountability, confidentiality, and integrity." (IEEE Std 1003.0-1995)
Single-standard Profile: "A single-standard profile (such as FIPS Publication 151-2) may consist of a subset of a particular standard or a single standard where parameters and options have been selected. This type of profile is often used when there is a wide range of options and parameters in a base standard and specifying these options can focus implementation efforts. It is important to be aware that some base standards reference other base standards normatively even when defining a singe-standard profile." (IEEE Std 1003.0-1995)
Software: "The programs, procedures, rules, and any associated documentation pertaining to the operation of an information processing system." (IEEE Std 1003.0-1995)
Spanning Service Area: Spanning service area volumes, as used in this ITSG, are constructed for any subject domain that crosses major service areas.
Specification: "A document that prescribes, in a complete, precise, verifiable manner, the requirements, design, behavior, or characteristics of a system or system component." (IEEE Std 1003.0-1995)
Standard: "A document, established by consensus and approved by an accredited standards development organization, that provides, for common and repeated use, rules, guidelines, or characteristics for activities or their results, aimed at the achievement of the optimum degree of order and consistency in a given context." (IEEE Std 1003.0-1995)
Standard Feature: "A function provided in a standard. Either a single facility or behavior, or, one of a pair of alternative facilities or behaviors, required by a standard that is always present on a conforming implementation." (IEEE Std P1003.2-1991)
Standard Profile: A profile of standards, not necessarily having gone through a process as a standardized profile.
Standardized Profile: "A balloted, formal, harmonized document that specifies a profile." (IEEE Std 1003.0-1995)
Standard Development Organization: "An accredited organization that formally develops and coordinates standards for use by a community. (IEEE Std 1003.0-1995)
Standards Implementation: A product that implements a standard.
Standard's Profile: see Profile, Standard's.
Supported: A condition regarding optional functionality. (ISO/IEC 9945-1)
System Documentation: "All documentation provided with an implementation, except the conformance document." (ISO/IEC 9945-1)
Tailoring Guidance: Guidance concerning a specific information processing standard on the specific features, modes, switch settings, functions, areas of deficiencies, extensions, levels, and options. This information is provided to tailor the specification for use to exploit it best for eventual transportability at the source code level.
Thread: "A single flow of control within a process." (IEEE Std 1003.0-1995)
Transaction: "A unit of work consisting of an arbitrary number of individual operations, all of which will either complete successfully or abort with no effect on the intended resources. A transaction has well-defined boundaries. A transaction starts with a request from the application program and either completes successfully (commits) or has no effect (abort). Both the commit and abort signify completion of a transaction." (IEEE Std 1003.0-1995)
Transaction Application Program: "Transactions have boundaries (start points and end points) that are determined by the action of the transaction application program. The transaction application program can request either to commit or roll back the work done in the transaction when it identifies the end point. The system will complete a commit operation only if all operations performed during the transaction can complete successfully. Otherwise, the system will abort the transaction (roll back the work done by it) and notify the transaction application program of this action." (IEEE Std 1003.0-1995)
Undefined: "An indication that a part of the standard imposes no portability requirements on an application's use of an indeterminate value on its behavior with erroneous program constructs or erroneous data." (ISO/IEC 9945-1)
Unspecified: "An indication that a part of a standard imposes no portability requirements on applications for correct program constructs or correct data regarding a value on behavior." (ISO/IEC 9945-1)
Validation: "The process of testing an application or system to ensure that it conforms to its specification." (IEEE Std 1003.0-1995)
2.7.1 Comments. The Center for Standards solicits comments on the ITSG and experiences in using standards from users of this document. Use of a standard format for submitting a change proposal will expedite the processing of changes. The following format is suggested for use in responding with comments or other useful information about specific instances of use of standards.
a. Point of Contact Identification
(2) Organization and Office Symbol:
(6) Zip Code:
(7) Area Code and Telephone #:
(8) Area Code and Fax #:
(9) E-mail Address:
b. Document Identification
(1) Volume Number:
(2) Document Title:
(3) Version Number:
(4) Version Date:
c. Proposed Change #1
(1) Section Number:
(2) Page Number:
(3) Title of Proposed Change:
(4) Wording of Proposed Change:
(5) Rationale for Proposed Change:
(6) Other Comments:
d. Proposed Change #2
(1) Section Number:
(2) Page Number:
(3) Title of Proposed Change:
(4) Wording of Proposed Change:
(5) Rationale for Proposed Change:
(6) Other Comments:
e. Proposed Change #n
(1) Section Number:
(2) Page Number:
(3) Title of Proposed Change:
(4) Wording of Proposed Change:
(5) Rationale for Proposed Change:
(6) Other Comments:
The preferred method of proposal receipt is via e-mail in ASCII format, sent via the Internet. If not e-mailed, the proposed change, also in the format shown, on both paper and floppy disk, should be mailed. As a final option, change proposals may be sent via fax; however, delivery methods that enable electronic capture of change proposals are preferred. Address information for proposing comments is shown below.
Internet: bookera @ ncr.disa.mil or email@example.com
Mail: DISA/JIEO/CFS or Logicon
Code: JEBEA (Angela Booker) Attn: John Pratt
10701 Parkridge Blvd 1831 Wiehle Avenue, Suite 300
Reston, VA 20191-4357 Reston, VA 20190-5241
Fax: 703-735-3257 or 703-318-1098
The status of comments on the ITSG are recorded in a database, and the comments themselves are distributed to working groups for resolution.