NIST RESEARCH

LIBRARY

APR 6

" 1998 NIST Special Publication 881-38

Federal Implementation Guideline

for Electronic Data Interchange

ASC X12 Version/Release 003070

FEDERAL CONVENTIONS FOR

USING ASC XI2 TRANSACTION SETS

Implementation Convention

Nisr U.S. DEPARTMENT OF COMMERCE

Technology Administration

National Institute of

Standards and Technology
rhe National Institute of Standards and Technology was established in 1988 by Congress to "assist industry in the development of technology . , . needed to improve product quality, to modernize manufacturing processes,

to ensure product reliability . . . and to facilitate rapid commercialization ... of products based on new scientific discoveries." NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S. industry's

competitiveness; advance science and engineering; and improve public health, safety, and the environment. One

of the agency's basic functions is to develop, maintain, and retain custody of the national standards of

measurement, and provide the means and methods for comparing standards used in science, engineering,

manufacturing, commerce, industry, and education with the standards adopted or recognized by the Federal

Government.

As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and

applied research in the physical sciences and engineering, and develops measurement techniques, test methods, standards, and related services. The Institute does generic and precompetitive work on new and

advanced technologies. NIST's research facilities are located at Gaithersburg, MD 20899, and at Boulder, CO 80303.

Major technical operating units and their principal activities are listed below. For more information contact the Publications and Program Inquiries Desk, 301-975-3058.

Office of the Director

• National Quality Program

• International and Academic Affairs

Technology Services

• Standards Services

• Technology Partnerships

• Measurement Services

• Technology Innovation

• Information Services Advanced Technology Program

• Economic Assessment

• Information Technology and Applications

• Chemical and Biomedical Technology

• Materials and Manufacturing Technology

• Electronics and Photonics Technology

Manufacturing Extension Partnership

Program

• Regional Programs

• National Programs

• Program Development

Electronics and Electrical Engineering

Laboratory

• Microelectronics

• Law Enforcement Standards

• Electricity

• Semiconductor Electronics

• Electromagnetic Fields'

• Electromagnetic Technology'

• Optoelectronics'

Chemical Science and Technology

Laboratory

• Biotechnology

• Physical and Chemical Properties'

• Analytical Chemistry

• Process Measurements

• Surface and Microanalysis Science

'At Boulder, CO 80303. ^Some elements at Boulder, CO.

Physics Laboratory

• Electron and Optical Physics

• Atomic Physics

• Optical Technology

• Ionizing Radiation

• Time and Frequency'

• Quantum Physics'

Materials Science and Engineering

Laboratory

• Intelligent Processing of Materials

• Ceramics

• Materials Reliability'

• Polymers

• Metallurgy

• NIST Center for Neutron Research

Manufacturing Engineering

Laboratory

• Precision Engineering

• Automated Production Technology

• Intelligent Systems

• Fabrication Technology

• Manufacturing Systems Integration

Building and Fire Research

Laboratory

• Structures

• Building Materials

• Building Environment

• Fire Safety Engineering

• Fire Science

Information Technology Laboratory

• Mathematical and Computational Sciences^

• Advanced Network Technologies

• Computer Security

• Information Access and User Interfaces

• High Performance Systems and Services

• Distributed Computing and Information Services

• Software Diagnostics and Conformance Testing
NIST Special Publication 881-38

Federal Implementation Guideline

for Electronic Data Interchange

ASC X12 Version/Release 003070

FEDERAL CONVENTIONS FOR

USING ASC X12 TRANSACTION SETS

Electronic Commerce Acquisition Program Management Office

Standard Management Committee - Secretariat

National Institute of Standards and Technology

Gaithersburg, MD 20899-0001

Editor: Dr. Jean-Philippe Favreau

January 1998

U.S. DEPARTMENT OF COMMERCE

William M. Daley, Secretary

Technology Administration

Gary R. Bachula, Acting Under Secretary for Technology

National Institute of Standards and Technology

Raymond G. Kammer, Director
Reports on Information Technology

The National Institute of Standards and Technology (NIST)'s Information Technology Laboratory (ITL)

develops standards and guidelines, provides technical assistance, and conducts research for computers

and resources. As part of the overall federal effort to establish a single face to industry for conducting

electronic commerce, ITL has been designated as the organization responsible for coordinating the

development of Federal Implementation Conventions (ICs) for Electronic Data Interchange (EDI). ICs are defined by functional-area experts who create and select options from standard EDI Transaction Sets to yield the implementations to be used for practical EDI. These ICs are made available to federal agencies

and industry by electronic means and this Special Publication Series.

National Institute of Standards and Technology Special Publication 881-38

Natl. Inst. Stand. Technol. Spec. Publ. 881-38, 70 pages (Jan. 1998)

CODEN: NSPUE2

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1998

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402
10.0 FEDERAL CONVENTIONS FOR

USING ASC XI2 TRANSACTION

SETS

This part of the Federal Implementation Guidelines defines the Federal transaction set conventions. It includes the instructions for implementing the control and security structures and defmitions of

the usage indicators and applicable codes.

This version of Part 10 of the Federal Implementation Guidelines,

based on the ANSI ASC XI 2 Version 003 Release 070 standards,

supersedes and cancels the August 1994 version of Part 10.

Except where specifically otherwise indicated, this document

directs how the agencies, components and activities of the United

States Federal government will exchange Electronic Data

Interchange (EDI) data formatted in accordance with the provisions

of the ANSI ASC X12 standards.

10.1 INTRODUCTION

FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

The power of the American National Standards Institute (ANSI)

Accredited Standards Committee (ASC) XI 2 standard is in its building block concept, which standardizes the essential elements

of business transactions. The concept is analogous to a "standard

bill of materiel and the construction specifications," which gives the

architect flexibility in what can be designed with standardized

materiel and procedures. The Electronic Data Interchange (EDI)

system designer, like the architect, uses the ASC X12 standards to build business transactions that are often different because of their function and yet utilize the ASC X12 standards. The "bill of

materiel and the construction specification" of ASC XI 2 are the standards found in the published technical documentation.

ASC X12.3, December 1996 —The Data Element Dictionary

specifies the data elements used in the construction of the segments

that comprise the transaction sets developed by ASC XI 2.

ASC X12.5, December 1996 —The Interchange Control Structure provides the interchange control segment (also called an envelope),

consisting of a header and trailer, for the EDI transmission; it also provides a structure to acknowledge the receipt and processing of

the envelope.

ASC XI 2.6, December 1996 —The Application Control Structure

defines the basic control structures, syntax rules, and semantics of EDI.

ASC XI 2.22, December 1996 —The Data Segment Directory

provides the definitions and specifications of the segments used in the construction of transaction sets developed by ASC XI 2.

BASELINE AS OF: 28 August 1997 1
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

ASC X12.58, December 1996 — The Security Structures define the data formats for authentication, encryption, and assurances in order

to provide integrity, confidentiahty, verification and nonrepudiation of origin for two levels of exchange of Electronic Data

Interchange (EDI) formatted data: ftinctional group and transaction

set level.

X12.59, December 1996 —The Implementation ofEDI

Structure/Semantic Impact provides a clear distinction between the syntax of XI 2 structures and the semantics of transaction set usage.

X12C/TG 1/95-65 — Technical Report Reference Modelfor the Acknowledgment and Tracking ofEDI Interchanges summarizes

the use of the ANSI ASC XI 2 control elements and standards for the acknowledgment and tracking of EDI interchanges.

International Telecommunication Union - Telecommunication

Standardization Sector (ITU-T) Recommendation X.509 (J 993)/

ISO/IEC 9594-8 (1995), Information Technology- Open Systems

Interconnection- The Directory : Authentication Framework. The

Directory, defines a framework for the provision of authentication

services by the Directory to its users. It specifies the form of

authentication information held by the Directory, describes how

authentication information may be obtained from the Directory,

states the assumptions made about how authentication information

is formed and placed in the Directory, defmes three ways in which

applications may use authentication information to perform

authentication, and describes how other security services may be

supported by authentication.

In addition to using existing standards to build specific transactions, the standards may be used to provide control and tracking of

interchanges if accomplished in a specific standardized approach.

ANSI ASC XI 2 has defmed and approved several control structures and Transaction Sets intended to augment EDI auditing and control systems. It is the intent of these standards to provide a tracking

mechanism for EDI data as it moves through the transmission cycle.

Through the implementation of these tracking tools and analysis of

the resulting information, delay or failures in delivery can be

identified and corrected.

The work accomplished by ANSI ASC XI 2C in this area produced

a generic acknowledgment model that has been adapted to support

Federal Government EDI processes. Implementation of the acknowledgment mechanisms identified by this model will provide

a basic capability to track interchanges as they flow from senders through Service Request Handlers (SRH) to receivers across the EC/EDI Infrastructure. (An SRH is a service provider whose

primary function is to provide communications services between

other components in the model.) This basic capability will provide

functionality for each component to determine translation and

transmission status, including current location and disposition of an

2 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

interchange. Use of the implemented acknowledgment mechanisms

to determine singular event status can provide components with the information necessary to obtain some level of confidence that interchanges are flowing through the infrastructure properly. Taken

as a sequence of acknowledgment events, the model provides

senders with a means to track interchanges from generation to delivery to a Service Request Handler at the boundary of the

infrastructure, without imposing the processing and

communications overhead that would be required for true application to application acknowledgments.

In addition, the implemented acknowledgment mechanisms of this model will allow individual components to build upon or enhance

their internal audit trail processes.

This part of the Federal Implementation Guidelines is meant to be

an overarching architecture of the control and security structure which the government is implementing in the Electronic Commerce

Infrastructure (ECI) and other government EC activities. However,

not all the parts of the architecture will be implemented

immediately. The specifics of which parts are actually

implemented will be defined in agreements between actual components in the trading network and architecture, such as Value

Added Networks (VANs) and government users of the ECI.

It is not the intent of this guideline to specify how the implemented

acknowledgment mechanisms are to be used. While support of

these mechanisms is required, their usage between infrastructure components will be as agreed between those components. As an

example, the use of certain acknowledgment mechanisms between

the government and VANs is specified in a VAN Licensing

Agreement (VLA). Where there is a conflict between the implementation guidance provided in Part 10 and the VLA, the VLA shall take precedence. Also, the use of acknowledgments

between Government Points of Translation (GPoT) and other

infrastructure components can be as mutually agreed upon.

The Service Level Agreement (SLA) between the ECI and the respective government Automated Information Systems (AIS) acts in a similar manner as the VLA. Where there is a conflict between

the implementation guidance provided in Part 10 and the SLA, the SLA shall take precedence.

By focusing on basic acknowledgment functionality that is independent of communications protocols, enhanced tracking of

interchanges is accomplished without requiring individual components to adhere to or support a full accountability system.

For further clarification of acronyms, abbreviations, and codes,

refer to ASC X12 published technical documentation. For copies, contact either the EDI focal point within your service or agency, or,

BASELINE AS OF: 28 August 1997 3
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

alternatively, contact the administering body (see Section 1.3 of

these guidelines).

4 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

10.2 CONTROL SEGMENTS

In addition to communications control, the EDI interchange

structure provides the standards user with multiple levels of control

to ensure data integrity. It does so by using header and trailer control segments designed to identify uniquely the start and end of

the interchange functional groups and transaction sets. The

relationship of these control segments is shown in Figure 10.2-1. Control Segment specifications are defined in Section 10.6.

10.2.1 Description of Use

The interchange header and trailer segments (ISA/IEA) along with

the optional interchange acknowledgment segments (TAl and TA3)

constitute the interchange control structure (i.e., an interchange

envelope). Interchange control segments perform the following

functions:

• Define data element separators, subelement separators and data segment terminators

• Provide control information

• Identify interchange sender and receiver

• Allow for authorization and security information.

The actual interchange control structure includes neither the group

control structures nor the transaction control structures; these are defined by ASC XI 2 as application control structures, and their version and release may differ fi-om those for the interchange

envelope. An interchange envelope encompasses one or more

functional groups (GS/GE), which, in turn, enclose one or more

related transaction sets (ST/SE). The relationship for these

structures is illustrated in Figure 10.2-1.

The purpose for GS/GE functional grouping is to provide an

additional control envelope surrounding like transaction sets conforming with a unique Implementation Convention (IC). Their usage is prescribed as interchange control segments in order to present a consistent methodology for electronic data interchange

within the government community and for commercial entities that conduct EDI business with the government.

Implementation Note: The Federal Government Electronic

Commerce Infrastructure (ECI) shall send and receive textual data

ASCII encoded. If unencrypted binary segments arefiltered. Base

64filtering shall be used.

BASELINE AS OF: 28 August 1997 5
Corrrnunications Transport Protocol

ISA

GS

ST

ST

IrtenJmiye Control Header

Functional Group Header

Transaction Set Header

Detail Segments

e.g., Puchase Order

TrarBaction Set Trailer

Transaction Set Header

Detail Segments

e.g., Puchase Order

Transaction Set Trailer

GE

GS

ST

SE

GE

lEA

Functional Group Trailer

Functional Group Header

Transaction Set Header

Detail Segments

e.g., Receiving Advice

Transaction Set Trailer

Functional Group Trailer

Interchange Control Trailer

ConmricatiorB Transport F^otocol

Note: When an Interchange contains TA3s, It shall contain only TA3s. The TA3s replace

all Functional Groups, Security Envelopes, Transaction Headers and Trailers, as well as

Detail Segments in the above diagram.

Figure 10.2-1. Hierarchical Structure.
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

10.2.1.1 Data Element, Data Segment, and Component Data

Element Separation

In ASC XI 2 documentation, the data element separator is graphically displayed as an asterisk (*). The actual data element

separator employed within the interchange envelope dictates the value for the entire interchange. The first occurrence of the data element separator is at the fourth byte of the interchange control

header. The value appearing there dictates the data element

separator used through the next interchange trailer.

In a similar manner, the interchange control header establishes the value to be used for segment termination within an interchange.

ASC XI 2 documentation represents this graphically by a new line (N/L). The first instance of segment termination occurs immediately following the ISA 16 data element, and the data value

occurring there sets the value for the interchange.

Designation of a component data element separator differs fi'om the other separators in that the ISA segment provides a discrete element

(ISA16) for defining the component data element separator data

value.

Implementation Note::

1. ASCII hexadecimal character IC shall be used as the segment

terminator in Federal Government interchanges.

2. ASCII hexadecimal character ID shall be used as the data

element separator in Federal Government interchanges.

3. ASCII hexadecimal character IF shall be used as the component

element separator in Federal Government interchanges.

4. These characters are reservedfor these purposes and shall not be used in data elements, except that they may be used in data

element 785, Binary Data.

10.2.1.2 Identification of Implementation Convention

The Federal Government develops and maintains Implementation

Conventions (ICs) based on ASC XI 2 standards. All entities conducting EDI business within the Government or externally with

the Goverrmient shall com.ply with all applicable ICs. ICs are available from National Institute of Standards and Technology

acting as the secretariat for the Federal EDI Standards Management

Coordinating Committee (FESMCC). Conventions on the use of

interchange control structures are provided herein to document a

consistent approach to control structure content. The functional group control structures include the ability to identify specific ICs

to which the Transaction Sets contained within that group conform.

BASELINE AS OF: 28 August 1997 7
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Interchange senders will provide the ASC XI 2 Version/

Release/Subrelease and implementation convention identifier in GS08. This identifier uniquely identifies the convention to which

the transaction set conforms.

Implementation Note: Envelope control segments havefew options

and, exceptfor minor tailoring, are identicalfor every EDI

interchange. The tailoring involves the code values selectedfor the GSOl and GS08 elements. GSOl classifies the particular

transaction set(s) within a functional group and GS08 identifies the

specific IC with which the transactions contained within the group

comply. (Note: The version and release identified in ISA 1 2 pertains

to the interchange control envelope, not to the contained

transaction sets.)

The Version/Release/Industry Identifier Code (GS08) is structured

as follows:

Positions 1 through 6:

Position 7

Positions 8 through 1

0

Position 1 1

Position 12:

ANSI ASC XI 2 Version and Release

number (e.g. 003010) upon which the IC is based.

Organizational Scope

F = Federal

D = DOD

G = Government (transitional)

Transaction Set Identifier Code (e.g., 850).

Derivative: A character used to differentiate between different functional implementations of the same transaction set.

If the convention is not a derivative, an underscore (_) will appear in this position.

A sequential number starting with 0

and incremented by 1 each time the convention is re-issued.

An example of the Version/Release/ Industry Identifier Code for XI 2 Version 003050, Federal Specific IC, revision 1, Commercial

Invoice (810C) is 003050F810C1.

10.2.1.3 Control Numbers

8 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

ASC X12 standards provide for syntax control on three levels: interchange, group, and transaction. Within each level, control numbers exhibit a positive match between the header segment and

its corresponding trailer (i.e., ISA/IEA, GS/GE, and ST/SE).

Assignment of these control numbers, at each level, is as follows:

Implementation Note: ISA/IEA Interchange Control Numbers

(ISAI3/IEA02).

1. The nine-digit interchange control number is usually assigned

by the originator 's translation software. Originating organizations

may use any numbering scheme consistent with their business

practices.

2. The scheme must provide sufficient uniqueness to identify each

interchange. Unique identification is defined as the triplet: Interchange Sender ID, (ISA05. ISA06). the Interchange Receiver

ID, (ISA07, ISA08) and the nine-digit Interchange Control Number

(ISAI3). This triplet shall be unique within a reasonably extended

timeframe.

3. If there is no TA3, Interchange Delivery Notice, after 2 hours, then retransmit with the same interchange control number (ISA 1 3).

4. If an interchange is rejected, the corrected interchange shall have a new interchange control number (ISA 1 3).

Implementation Note: GS/GE Data Interchange Control Numbers

(GS06/GE02).

1. This is a one to nine^digit number usually assigned by the originator 's translation software. This number uniquely identifies functional groups transmitted between sending and receiving

application pairs. Originating organizations may use any

numbering scheme consistent with their business practices.

2. The scheme must provide sufficient uniqueness to identify each

functional group. The Group Control Number value (GS06),

together with the Application Sender's Code (GS02), Application

Receiver 's Code (GS03), and Functional Identifier Code (GSOI),

shall be unique within an extended timeframe — such as a year.

Implementation Note: ST/SE Transaction Set Control Numbers

(ST02/SE02). The originator 's translation software usually assigns

the transaction set control number. Originating organizations may

use any numbering scheme consistent with their business practices.

The scheme must provide sufficient uniqueness to identify each

transaction set, within the context ofthe functional group.

The control numbers within corresponding header and trailer segments must match. This provides a means to detect loss of data.

BASELINE AS OF: 28 August 1997 9
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

10.3 ADDRESSING

The purpose of addressing is to provide an unambiguous reference

to a transmission's sender and intended receiver. The addressing

model used by the Federal Government for ASC XI 2 EDI

transmissions is graphically depicted in Figure 10.3-1. In this model, there is addressing for two types of transmissions. The first

is an interchange. It consists of control segments and application

data. The second type is application data. Application data flow

from the sending to the receiving applications and is transported

within an interchange. Since interchanges are assembled by the sending translation point and disassembled by the receiving

translation point, the flow of an interchange is defined to be from

translation point to translation point. Application data must be

provided to the sending translation point by the sending application

and is depicted as a User Defined File (UDF). It must also be

provided to the receiving application by the receiving translation point and is also depicted as a UDF.

While the model depicts data flow from the government to a vendor, it is equally applicable in the reverse flow.

LlLIili F I :i A A

Interchange 5^ ZZ

Routing A A

IS AO6

Interchange Sender

IS AOS

Interchange Receiver

ID

GS02

Application Senders Code

GS03

Application Receiver's

GPoT = Government Point of Translation IPoT = Industry Point of Translation

Figure 10.3-1 Addressing M odel

Figure 10.3-1 Addressing Model

10.3.1. Interchanges

Interchanges flow between translation locations. The Government

Point of Translation (GPoT) can be implemented as part of the government Application Information System (AIS), as part of the Electronic Commerce Processing Node (ECPN), or as a stand-alone

function. Likewise, the Industry Point of Translation (IPoT) on the

10 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

vendor side can be in the Vendor Application, as part of the VAN's

services, or as a stand-alone function.

The GPoT and IPoT are addressed by the Interchange Sender ID

(ISA05 and ISA06) and Interchange Receiver ID (ISA07 and

ISA08) data elements. These, combined with the Interchange

Control Number (ISA 13), create a triplet that defines a globally

unique identifier for the interchange. The ASC X12 Interchange

flows between these translation points.

Implementation Note:

1. When an interchange contains one-to-one transactions, the Interchange Sender ID (ISA06) and Interchange Receiver ID

(ISAOS) data elements shall be the addresses ofthe interchange

translation points (both government and non-government).

2. Translation Points (ISA06 and ISA08) shall be identified via a unique identifierfrom one ofthe sources listed as allowable codes

in the ISAO5 definition in section 10.6. The Data Universal

Numbering System (D-U-N-S) number and D-U-N-S +4 are the preferred identifiers.

3. All commercial and government entities conducting business

electronically shall provide their translation point (ISA06/ISA08)

codes during registration.

4. In the ECI, when an interchange contains public transactions

the ISAOS will be addressed individually to all certified VANs, not

necessarily each IPoT. The ISA06 will contain the ECPN's

address.

10.3.2 Application Sender and Receiver Codes

Application data is transported within the mterchange via groups. Group addressing (GS02/GS03) must define the user application

end points shown in figure 10.3-1 as the AIS and the Vendor

Application. These addresses are locally unique and are defined

between the translation point and its customers. The data that flows

between the translation points and the Application Senders and

Receivers are not defined by ASC XI 2, but are in a format agreed

between the applications and their translation points.

ASC XI 2 standards provide for the identification of senders and

receivers on two levels, the interchange and the group. The group

level identifies application senders and receivers. Depending on

where translation is performed, the sender/receiver IDs may be the same at the interchange and group levels and may use any number

of available naming schemes.

At the GS/GE level, D-U-N-S and D-U-N-S plus 4 are recommended, especially for identifying government organizations.

Other identifiers may be used.

BASELINE AS OF: 28 August 1997 11
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

A D-U-N-S number may be acquired from Dun and Bradstreet and

the plus 4 portion of the number is assigned and maintained

internally by each entity. Specific use of these numbers is provided

for in the control structures section of this document.

Implementation Note:

1. The GS02/03 identifiers need be unique only within the context ofthe associated ISA address.

2. All commercial and government entities conducting business

electronically shall provide their Application Sender and Receiver

(GS02/GS03) codes during registration.

12 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

10.4 ACKNOWLEDGMENTS

The successful conduct of business via EDI requires that trading

partners be able to determine when transactions were received, not

received, received in error, or otherwise did not complete the transmission or receiver application processing cycle. The

generation or handling of these events may be communications

based, EDI processing based, or both. In addition, senders may

desire to know such information on an exception basis, such as reporting only for error conditions, or they may need regular

indication of the status of delivery to allow them to maintain local, internal audit information. Also, providers of communications

services may need to know when interchanges for which they have

accepted responsibility were forwarded and accepted by the next

service provider in the transmission path, or whether forwarding was not successful.

In either scenario, the transmission or processing of interchanges can be viewed as an acknowledgment event in a general sense, creating the need for some response. From a sender's perspective,

the acceptance of their interchange by a translator or communications provider is an acknowledgment event that could

either be indicated by a simple receipt, or a more thorough

reporting of what actions were taken after receipt. For a service provider, forwarding interchanges can also result in an acknowledgment event being created that calls for an acknowledgment action to take place.

Taken as a set of acknowledgment requirements, these and other events can be considered as a set of circumstances which results in or require some acknowledgment action to take place. Rather than

consider every possible action and event, a basic sub-set of these events can be defined that describes the majority of cases that form

a generalized picture of tracking interchanges. Together with

acknowledgment mechanisms that relate to those events and

specific components that create or respond to those events, an acknowledgment model can be described.

ANSI ASC X12C has worked in this area, having produced a generic Acknowledgments Model in X12C/TG1/95-65 — Technical

Report Reference Modelfor the Acknowledgment and Tracking of

EDI Interchanges. This technical report identifies specific entities in the EDI communications and processing path that serve as the event generators or handlers, as well as identifying XI 2 standards based acknowledgment mechanisms. Also, the senders and

receivers of the interchanges are recognized as being the terminating application systems for which the EDI transactions are sent from or sent to, regardless of where translation occurs. The

government has taken the ANSI XI 2 approach to an acknowledgments model, refining it through identification of

specific entities and acknowledgment events. Support for this model will provide users and service providers with the ability to track interchanges and respond to requests for status of such

BASELINE AS OF: 28 August 1997 13
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

interchanges. In addition, the internal audit trail processes of each

entity will be enhanced with the availability of specified event mapping.

10.4.1 Description of Acknowledgment IVIodel

As adapted from the generic model developed within ASC X12C,

the Government Acknowledgment Model identifies specific

components, acknowledgment events, and XI 2 mechanisms that are related to those events. Based upon the Electronic Commerce

Processing Node (ECPN) as a central component, the model

establishes a view of the EC/EDI Infrastructure as encompassing

commercial and government entities, as well as service providers

and users.

In this model, service providers are those components that provide

translation services, communications services, or some EDI

processing services. Specifically, the model identifies the ECPNs,

VANs and Translation Points as service providers. A Service

Request Handler (SRH) is a service provider whose primary

function is to provide communications services between other components in the model. Users include Trading Partners (TPs)

and Automated Information Systems (AISs).

The acknowledgment mechanisms identified in the model include

unspecified as well as X12 based mechanisms. Where the model

has identified an acknowledgment event but does not specify a mechanism for handling that event, it is implied that components

involved in that event will agree on what mechanism will be used.

XI 2 based acknowledgment mechanisms include control segment

structures in addition to transaction sets. The Interchange Delivery

Notice (TA3) segment, Data Status Tracking (242) transaction set and the Functional Acknowledgment (997) transaction set all have

distinct properties and functions. However, their use in a general sense as acknowledgment mechanisms allows a sequence of

communications and processing events to be tied together in a

logical stream. Each acknowledgment event is mapped to an XI

standards based mechanism according to where the event takes

place, what type of event occurred, and what role the receiving or generating component plays in the data flow stream.

The TA3 can provide information on the status of delivery of an

interchange, the time an interchange was received, or the disposition of an interchange, and is used to report such information

between Service Request Handlers. The Data Status Tracking

(242) transaction set, in addition to providing the ability to represent the information contained in the TA3, allows transmission

status information to be conveyed from service request handlers to senders. The Functional Acknowledgment (997) transaction set indicates the status of translation of the interchange header and

trailer information. These mechanisms are more fully described

later in this section.

14 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

The model, as depicted in Figures 10.4-1, 10.4-2, 10.4-3, and 10.4-

4, identifies the sets of events that, through implementation and use of the specified acknowledgment mechanisms, provides for the tracking of interchanges across the infrastructure.

Implementation Note:

1. While the requirementfor acknowledgments from Government

Points of Translation (GPoT) to supported AISs was identified, no

single mechanism could be identified. It is therefore left to agreement between them as described in the Service Level

Agreement.

2. TA 1 is not supported in this acknowledgment model

implementation.

3. The government translation function can be implemented as part

ofthe government Application Information System (AIS), as part of

the Electronic Commerce Processing Node (ECPN), or as a stand- alonefunction. GPoT acknowledgment responsibilities reside at the location performing translation.

4. The vendor translation function can be implemented as part of

the Vendor Application, Value Added Network (VAN) or as a

stand-alonefunction. IPoT acknowledgment responsibilities reside

at the location performing translation.

BASELINE AS OF: 28 August 1997 15
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

VAN IPoT Vendor

Application

Acknowledgment Flow

Notes:

a. The GPoT translation function may be performed by the ECPN, AIS, or by a separate entity.

b. For the purposes of the model, the govt-to-govt scenario is represented by replacing the VAN-Translation components with a GPoT component.

c. The IPoT may be operated by the VAN, the Vendor, or a third party. In all cases, the IPoT is the ultimate

recipient of the interchange for the purposes of acknowledgment in this model.

d. 997s and 242s can be mapped at the GPoT to UDFs & forwarded to the AIS as agreed between the GPoT

and their customer base. 242s will not be acknowledged by 997s.

e. UDF is User Defined File (flat file, proprietary file).

f. The use of 824s are not precluded by this model.

g. Support for the model acknowledgment mechanisms is mandatory. The manner of their usage is as detailed further in the Federal EDI Implementation Guidelines Part 10, or other agreements.

Figure 10.4-1 Acknowledgment Model, Commercial to Government

Sequence / Event Mechanism From To

1. Receipt of UDF by GpoT TBD GPoT AIS

2. Translation Result TBD GPoT AIS

3. Disposition (Acknowledge that interchange TBD GPoT AIS

has left GPoT)

4. Interchange receipt by ECPN 242 ECPN GPoT

5. Interchange Disposition at SRH TA3 VAN ECPN

(Government to Government) TA3 GPoT ECPN

5 a Report of Interchange Disposition at SRH 242 ECPN GPoT

5b. Report of Interchange Disposition at SRH UDF GPoT AIS

6. Translation Result 997 IPoT GPoT

6a Translation Result UDF GPoT AIS

Notes:

a. Not all events 1 , 2 or 3 may occur or need to be acknowledged

b. TBD indicates the acknowledgment mechanism is to be determined, or as agreed to between components

c. UDF: User Defined File (flat file, proprietary file format)

Figure 10.4-2 Acknowledged Events, Commercial to Government

16 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070FED1

TA3 TA3

N otes;

a. Acknowledgments among VANs, Translation Points and their customers are matters to be decided by them and are not defined in the government Acknowledgment Model.

b. Some GPoTs may generate a second 242, with the ECPN acting as a pass-through.

c. For government to government scenario, replace the VAN with a GPoT. The ECPN will generate 242s in lieu of TA3s in step 1 .

Figure 10.4-3 Acknowledgment Model, Government to Commercial

Sequence / Event Mechanism From To

1 . Interchange receipt by ECPN TA3 ECPN VAN

(Government to Government) TA3 ECPN GPoT

2. Interchange Disposition at GpoT TA3 GPoT ECPN

2a. Report of Interchange Disposition at GPoT 242 ECPN VAN

(Government to Government) 242 ECPN GPoT

3. Translation Result 997 GPoT IPoT

Note:

In step 2a, the disposition report carried in a TA3 is mapped to a 242

Figure 10.4-4 Acknowledged Events, Government to Commercial

BASELINE AS OF: 28 August 1997 17
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

10.4.2 Interchange Acknowledgment

At the interchange level, acknowledgments can occur for a number

of events. Successful translation, syntax error, or a more detailed acknowledgment of the disposition of an interchange can be

reported. The available XI 2 mechanisms for such interchange

acknowledgments includes the Functional Acknowledgment (997)

transaction set, the Interchange Acknowledgment (TAl ), and the Interchange Delivery Notice Segment (TA3). In general, the 997 is used exclusively for reporting the status of syntactical analysis of

the interchange by the receivmg translator, although it could be

used as an indication that an interchange was received. The

Interchange Acknowledgment (TAl) is not supported in this acknowledgment model. The Interchange Delivery Notice (TA3)

provides the ability for reporting on the status of actions taken on a

particular interchange. The manner in which these mechanisms are used, and the features within each that are utilized, provides a set of

tools for building a sequence of acknowledgments for the life cycle

of an interchange as it flows across an infrastructure.

10.4.2.1 TA3

The purpose of the TA3 is to provide a notice from the receiving

SRH to the sending SRH that an interchange was delivered, not

delivered, refused, purged, or transferred to the next SRH. It provides a notification of action taken, notice of time/date action was taken, and the ability to report on more than one event.

As an acknowledgment mechanism in this model, the TA3 is used

between the ECPN and VANs, as Service Request Handlers, to indicate the status of interchanges sent from the government to commercial components, as well as the reverse scenario. To

indicate outbound delivery status, the information contained in this TA3 is further translated into a 242 transaction set and sent to GPoTs for their use, which may include supplying this information

to the interchange sender. The government uses the TA3 to indicate interchange delivery status to the sending commercial infrastructure components.

Implementation Note:

1. An interchange that contains a TA3 shall contain only

TA3s.

2. An interchange may contain multiple TASs.

3. Upon delivery to the interchange receiver's mailbox, a TA3

shall be generated.

4. Ifdeliveiy to the interchange receiver 's mailbox is not made within 2 hours, a TA3 shall be generated indicating a nondeliveiy status. The appropriate reason codes will be specified. A

TA3 shall be generated eveiy 2 hours indicating non-deliveiy status

18 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

until the interchange is delivered to the receiver 's mailbox. Upon

delivery, note 3 above applies.

5. Ifan interchange is accepted but subsequently determined

to be non-deliverable, a TA3 shall be generated indicating code RJ

in TA3J2 and the appropriate reason code in TA303.

- - 6. No acknowledgment is madefor the receipt ofa TA3.

10.4.2.2 Data Status Tracking (242) Transaction Set

The Data Status Tracking (242) transaction set conveys status information from a service request handler to the interchange

sender, interchange receiver, or both. It can be used to provide

status information regarding an interchange as it flows from an

interchange sender through one or more service request handlers to an interchange receiver during its transmission cycle.

In the acknowledgment model, the 242 transaction set is used for two events: (1) it conveys information from the TA3 that was

generated by the VAN or GPoT that received the interchange, and

(2) it is used to provide acknowledgment information between

government components. Because it is a transaction set, translation

sites can map that information into a UDF for the sending

applications use. How this information is used depends on the

internal business processes at the application site, and is not covered by the model. In addition, this information may be used by

the GPoT in its capacity as a Service Request Handler for internal audit trail purposes.

Implementation Note:

1. For interchanges between government components, a 242 shall be generated upon delivery to the interchange receiver 's mailbox.

Ifdelivery to the interchange receiver 's mailbox is not made within 2 hours, a 242 shall be generated indicating a non-delivery status.

2. The 242 transaction set shall not be acknowledged (via a 997), nor shall it be used to report the final disposition ofa 997

transaction set

3. Additional 242 acknowledgmentsfrom interconnect service

providers may be required by additional agreements among trading

partners.

10.4.2.3 Interchange Acknowledgment Segment (TA1)

The Interchange Acknowledgment Segment (TAl) is used to acknowledge receipt of one interchange header and trailer envelope.

Implementation Note: The TAI is not supported in this acknowledgment model.

BASELINE AS OF: 28 August 1997 19
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

10.4.3 Application Advice (824) Transaction Set

Although it can provide acknowledgment functionality, use of the Application Advice (824) transaction set is not specified by this model. Currently, it is primarily used on an exception basis for reporting between applications, and its full use as an acknowledgment mechanism within the model would create

substantial impact on the communications and processing systems.

10.4.4 Functional Acknowledgments (997)

Transaction Set

While the Functional Acknowledgment (997) transaction set is not

part of the interchange control structure, it is integral to the overall process for interchange integrity, and for completeness of the acknowledgment model.

Support for the Functional Acknowledgment is required in all cases. The 997 verifies (or challenges) the syntactical correctness

(e.g., ability to translate) of transaction-level data within a functional group.

Implementation Note:

1) Syntactic correctness shall be determined by comparison to the requirements ofthe applicable implementation convention, not

simply the ASC XI 2 standard.

2) The 997 transaction set shall not be acknowledged.

3) When an X12 transaction containing "Not Used" segments

and/or data elements is received by the Government, the transaction will be rejected and a 997 will be generated indicating

why the transaction was rejected.

20 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

10.5 SECURITY

ASC X12.58, published in December, 1996, provides for the implementation of security services at the functional group and

transaction set levels. The available security services include: data

integrity, confidentiality, assurance, verification, and nonrepudiation of origin. These services may be implemented

individually or in any combination.

ASC X12.58 can meet several security objectives. Among these

are:

• The recipient of an EDI transaction can verify the identity of

the originator of the transaction.

• The recipient of an EDI transaction can verify the integrity of

its contents.

• The originator of an EDI transaction can provide

confidentiality for its contents.

ASC XI 2. 5 8 provides a mechanism that can be applied to the XI

functional group or transaction set, in contrast to other alternatives which are usually applied to the entire interchange. ANSI XI 2. 5

8

is transaction data independent. When XI 2. 5 8 security

mechanisms are applied inside the interchange, they can be handled

and routed as standard XI 2 transactions without disrupting the endto-end security. Since security services are applied within the interchange, they are independent of the mechanism used to transport them. Thus X12.58 can provide security even when the interchanges leave the boundaries of the ECI.

The Federal Government is committed to providing security

services for ASC XI 2 compliant EDI via the constructs provided by

ASC X12.58. However, very significant changes to those

constructs have been made within various version/releases of the ASC X12 standards. Also, ASC X12.58 security constructs are not backward compatible. That is, 003070 constructs may not be

applied to provide security services to the bulk of the current

federal implementations, which are in version/release 3060,

003050, 3040 and earlier.

10.5.1 Authentication

• Message authentication is a procedure to verify that received

messages have not been altered. A hash function, a public

function that maps a message of any length into a fixed hash

value, can be used as an authenticator when used in

21 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

conjunction with some form of data encryption, such as digital

signature.

Implementation Note: Assurance via the S2A/SVA segments shall be used in lieu ofauthentication.

10.5.2 Confidentiality (Encryption)

The XI 2. 5 8 standards allows for the implementation of various

algorithms to encrypt X12 transactions. Cryptographic algorithms

fall into two categories: secret key and public-key. Secret key

algorithms are based on both the sender and receiver sharing the same secret key (i.e., key unknown to other parties). This key is used to encrypt the transaction prior to transmission and decrypt it upon receipt. Public-key algorithms are based on both sender and

receiver having a pair of keys, one public and one private. All exchanges of keys between sender and receiver are limited to the public portion only, so the private key portion is protected.

Initially, the Government will support the following encryption

algorithms:

• Data Encryption Standard (DES)

• Triple DES (DE3)

• Rivest-Shamir-Adleman (RSA)

• SKIPJACK

Implementation Note:

1. Confidentiality services may be applied at either the functional

group (GS/GE) level, the transaction set (ST/SE) level or both.

2. When applied, the SIS shall be inserted immediately after the GS segment and the SJE shall be inserted immediately prior to the GE segment

3. When applied, the S2S shall be inserted immediately after the ST

segment and the S2E shall be inserted immediately prior to the SE

segment.

10.5.3 Assurance (Digital Signatures)

A digital signature is an authentication technique that also includes measures to counter repudiation by the source. Assurances (SI A or S2A and SVA), as defined in X12.58, allow the originator of the transaction to express "business intent" via a digital signature. The

Government will support implementation of the Digital Signature

Standard. When used, one S2A and one SVA are inserted immediately before the SE segment of the transaction set being

assured. If subsequent assurances are applied, additional S2A/SVA

pairs are inserted between the previous assurance, and the SE

22 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

segment of the transaction set being assured. Detailed instructions

for the use of the S2A and SVA segments are contained in section 10.6

Implementation Note:

1. Assurance (digital signature) may be applied at either the functional group (GS/GE) level, the transaction set (ST/SE) level or

both.

2. When digital signature is applied at the group level, the SIA and

SVA segment pair(s) shall be inserted immediately preceding the GE segment ofthe group being assured (digitally signed).

3. When digital signature is applied at the transaction set level, the SIA and SVA segment pair(s) shall be inserted immediately

preceding the SE segment ofthe transaction set being assured

(digitally signed).

4. When both assurance and confidentiality are applied, assurance

(SIA or S2A and SVA) shall be appliedfirst and then confidentiality

(SIS and SIE or S2S and S2E).

10.5.4X12.58 Capabilities by Release

ANSI X12

Release

Authentication ncryption jAssurance

j 3040 (Note 1) (Note 3) 3050 (Note 1) (Note 3) 3060 (Note 2) X X

3070 (Note 2) (Note 3) X

NOTES:

1 . Authentication accomplished using a message authentication code

(MAC). The MAC is a hash of the data.

2. Authentication accomplished as a by-product of the digital signature or by using the MAC defined in earlier releases of the ANSI XI 2 standard.

3. Private (symmetric) keys supported by this release. Asymmetric keying

is possible but not without some "non-standard" use of data elements.

10.5.5 Sequencing of Cryptographic Techniques

In practical situations, the users of the X12.58 standards will choose

combinations of features rather than just a single feature. This is possible

since all features are designed to be used in isolation or in any

combination.

Authentication does not protect the confidentiality of the message because

the information is interchanged in its plain text form. Message encryption

BASELINE AS OF: 28 August 1997 23
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

can be used to provide confidentiality while using authentication to provide integrity protection of the same data. When both authentication

and encryption are used, the authentication is performed before encryption

of the original plain text data.

Where more than one service is selected at a specific level, the order of

processing is:

a. Before applying any security services, the data must first be translated

into an EDI format

b. Addition of one or more assurances

c. Authentication

d. Compression

e. Encryption

f. Filtering for data communications

When assurance segments are used, they must be added to unsecured (not

authenticated or encrypted) transactions. If a transaction set is received

(with or without assurances) with encryption and/or authentication applied

by the originator, the transaction set must be either decrypted or authenticated prior to the addition of any further assurances. Once any

assurances have been added, the transaction set can be encrypted or authenticated prior to being forwarded to additional parties.

When applying security sei"vices at the functional group level, all security

services at the transaction set level must be completed before applying

security services at the functional group level.

The receiving organization processes the received message in the reverse

order, starting with inverse filtering, followed by decryption, and then by

decompression, validation of authentication and validation of the assurances. When processing inbound security services at the transaction

set level, all security services at the functional group level must be

removed before processing inbound security services at the transaction set

level. In this manner the receiving organization unwraps the EDI

message by processing the security services and removing the security

segment pairs from the message before processing the next security

service.

10.5.6 Transmission of Security Segments

Security services (authentication, encryption and assurances) are provided

at two levels within ASC XI 2 in conjunction with the following

envelopes:

• Functional Group (GS/GE envelope)

• Transaction Set (ST/SE envelope)

At each of these levels, authentication, encryption and assurances are each

optional. Assurances are independent of authentication or encryption. In

addition, any service used at one level is independent of a service used at the other level.

24 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

llViKLclVlcN 1 A 1 IvJN oUIUcLINtO

ANSI ASC X12 VERSION/RELEASE 003070

It encryption and/or authentication is provided, the secunty header

segment (SIS or S2S) immediately follows the segment initiating the beginning of this level (GS or ST); the security trailer segment (SIE or S2E) precedes the segment terminating the level (GE or SE). If assurances

are present, the SI A or S2A segments and its trailing SVA segment

immediately precedes the SE or GE if authentication and/or encryption is not used and immediately proceed the SIE or S2E segment if authentication and/or encryption is used. If encryption and/or

authentication at both levels is provided and if assurances are used at both levels, the sequence of segments, illustrating these levels, is:

TO A T J.— —l- _ TT — J ISA-Interchange Header

(Other Groups whether secured or not at Level 1) GS-Functional Group Header

S 1 S-Security Header Level 1 (Other Transaction Sets whether secured or not at Level 2)

SI- Transaction Set Header

ozb-oecunty Header Level z (The Transaction Set Segments)

A O ' J— A T 1 ^ S2A - Secunty Assurance Level 2 bVA - Assurance loken Level 2 (Other optional bZA-b\A pairs at Level z S2E-Security Irailer Level 2 SE-Transaction Set Trailer (Other Transaction Sets whether secured or not at Level 2) SI A - Assurance Segment Level 1 SVA - Assurance Token Level 1 (Other optional SIA-SVA pairs at Level 1) S IE-Security Trailer Level 1 GE-Functional Group Trailer (Other Functional Groups whether secured or not at Level 1

)

lEA-Interchange Trailer

BASELINE AS OF: 28 August 1997 25
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

10.6 Interchange Control, Acknowledgment and

Security Segment Specifications

This section contains the implementation conventions for the:

• Interchange Control Header (ISA), Version/release 003070

• Interchange Delivery Notice Segment (TA3)

• Functional Group Header (GS), Version/release 002003

• Functional Group Header (GS), Version/release 003010

• Functional Group Header (GS), Version/releases 003040

tnrougn UUiU/U

• Security Header Level 1 (SIS), Version/releases 003040 and

• Security Header Level 1 (SIS), Version/releases 003060 and

Amfind UUiU/U

• Security Header Level 2 (S2S), Version/releases 003040 and

• Security Header Level 2 (S2S), Version/releases 003060 and

AAT ATA OUiO/0

• Security Assurance Level 2 (S2A), Version/releases 003060

and 003070

• Assurance Token Level 2 (S2A), Version/releases 003060 and

AATATA 0030/0

• Security Trailer Level 2 (S2E), Version/releases 003060 and

003070

• Assurance Segment Level 1 (SIA), Version/releases 003060

and 003070

• Assurance Token Level 1 (SVA), Version/releases 003060

and 003070

• Security Trailer Level 1 (SIE), Version/releases 003060 and

• Functional Group Trailer (GE),

• Interchange Control Trailer (lEA), Version/release 003070

26 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

ISA Interchange Control Header

Mandatory

1To start and identify an interchange of zero or more functional groups and interchangerelated control segments

Segment:

Usage:

Max Use: Purpose:

Syntax Notes: Semantic Notes: Comments:

Notes: L Use ASCII Hexadecimal ID in thefourth byte ofthe Interchange Control Header.

Thisfirst occurrence ofan element separator dictates the value the translation

software will employ throughout the interchange.

2. Use ASCUHexadecimal IC after ISA16. Thisfirst occurrence ofa segment

terminator dictates the value the translation software employs throughout the

interchange.

3. See ISA16for subelement separator usage.

Must Use

Ref. Pes. ISAOl

Must Use ISA02

Data

Element

101

102

Data Element Summary

Name Attributes

Authorization Information Qualifier M ID 2/2

Code to identify the type of information in the Authorization Information

GO No Authorization Information Present (No Meaningful

Information in 102)

05 Department of Defense (DoD) Communication

Identifier Use to indicate the Department ofDefense (DOD) as

the information authorizer. Use this code even ifthe

sender is not a DOD entity.

06 United States Federal Government Communication

Identifier Use to indicate the Federal Government as the

information authorizer. Use this code even if the

sender is not a Federal Government entity.

Authorization Information M AN 10/10

Information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the Authorization Information Qualifier (101)

1. Use to provide additional identification or authorization for the data in the

interchange. Otherwise, fill thisfield with blank characters.

2. When used, it is recommended that the specific coding be exchanged

between trading partner data security officials to ensurepreservation ofdata

security.

BASELINE AS OF: 28 August 1997 27
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Must Use ISA03

Must Use ISA04

Must Use ISA05

Must Use ISA06

103 Security Information Qualifier M ID 2/2

Code to identify the type of information in the Security Information

00 No Security Information Present (No Meaningful

Information in 104) 01 Password

Use based on trading partner agreement,

104 Security Information M AN 10/10

This is used for identifying the security information about the interchange

sender or the data in the interchange; the type of information is set by the Security Information Qualifier (103)

IfISAOS is code 00, fill this field mth blank characters. Otherwise, enter a password as agreed between Trading Partners. 105 Interciiange ID Qualifier -

- -^-^ -^ ^

Qualifier to designate the system/method of code structure used to designate

the sender or receiver ID element being qualified

P-U-N-S (Code 01) or D-U-N-S+4 (Code 16) are prefered.

01 Duns (Dun & Bradstreet)

02 SCAC (Standard Carrier Alpha Code)

04 lATA (International Air Transport Association)

08 UCC EDI Communications ID (Comm ID)

09 X.121 (CCITT)

10 Department of Defense (DoD) Activity Address Code

1 6 Duns Number With 4-Character Suffix

106 Interchange Sender ID M AN 15/15

Identification code published by the sender for other parties to use as the receiver ID to route data to them; the sender always codes this value in the sender ID element

7. Enter the identifier ofthe sender's translation point.

Must Use ISA07

Must Use ISA08

2. Leftjustify andpad on the right with blanks. 105 Interchange ID Qualifier M ID 2/2

Qualifier to designate the system/method of code structure used to designate

the sender or receiver ID element being qualified

D-U-N-S (Code 01) or D-U-N-S+4 (Code 16) are prefered

01 Duns (Dun & Bradstreet)

02 SCAC (Standard Carrier Alpha Code)

04 lATA (International Air Transport Association)

08 UCC EDI Communications ID (Comm ID)

09 X.121 (CCITT)

10 Department of Defense (DoD) Activity Address Code

1 6 Duns Number With 4-Character Suffix

107 Interchange Receiver ID M AN 15/15

Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them

ii. Enter the identifier ofthe receiver's translation point (both government

'find non-government).

28 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Must Use ISA09

2. Leftjustify andpad on the right with blanks. 108 Interchange Date M DT 6/6 Date of the interchange

1. Express the UTC (previously known as GMT) date that this interchange was created.

Must Use ISAIO

2. Express the date in a six-position (YYMMDD)format.

109 Interchange Time M TM 4/4

Time of the interchange

/. Express the UTC (previously known as GMT) time that this interchange was created.

Must Use ISAll

Must Use ISA12

Must Use ISA13

Must Use ISA14

Must Use ISA15

2. Express the time in a four-position (HHMM)format.

110 Interchange Control Standards Identifier M ID 1/1 Code to identify the agency responsible for the control standard used by the message that is enclosed by the interchange header and trailer U U.S. EDI Community of ASC XI 2, TDCC, and UCS

111 Interchange Control Version Number M ID 5/5

This version number covers the interchange control segments

Use to identify the ASCX12 version and releasefor the interchange

envelope, not the transactions carried within the envelope.

00307 Draft Standards for Trial Use Approved for Publication

by ASC X12 Procedures Review Board through

October 1996

112 Interchange Control Number M NO 9/9

A control number assigned by the interchange sender

Originating activities may use any numbering scheme consistent with their business practices. However, the scheme must uniquely identify each

interchange over a very long period oftime. 113 Acknowledgment Requested M ID 1/1 Code sent by the sender to request an interchange acknowledgment (TAl)

This requestfor acknowledgment applies only to return ofa TAl,

Interchange Acknowledgment It does not apply to other acknowledgments

(e.g. TA3 or transaction set 242) as required by Part 10 ofthe Federal

Guidelines. Since the TAl is not supported, no acknowledgment shall be

requested.

0 No Acknowledgment Requested

Use this code to indicate an interchange

acknowledgment via TAl shall not be returned by the

interchange receiver. 114 Test Indicator M ID 1/1 Code to indicate whether data enclosed by this interchange envelope is test or production

P - Production Data Use to identify all data other than test data. T Test Data Use when testing interchanges.

BASELINE AS OF: 28 August 1997 29
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Must Use ISA16 115 Component Element Separator M AN 1/1 Type is not applicable; the component element separator is a delimiter and not

a data element; this field provides the delimiter used to separate component

data elements within a composite data structure; this value must be different than the data element separator and the segment terminator

Enter ASCII Hexadecimal IF. The value ofthis element dictates the value

the translation software employsfor component element separation

throughout the interchange.

30 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes:

Semantic Notes:

Comments:

Notes:

TA3 Interchange Delivery Notice Segment

Mandatory

1To provide a notice from the receiving service request handler to the sending service request handler that an interchange was delivered or not delivered to the interchange

receiver's mailbox, or some other ancillary service was performed, and that the interchange receiver retrieved, refused, or purged the interchange; TA3 is exchanged

only between service request handlers; use of the TA3 segment is optional

1 If either TA322 or TA323 is present, then the other is required.

2 If either TA324 or TA325 is present, then the other is required.

3 If either TA326 or TA327 is present, then the other is required.

1 TA301 and TA302 identify the service request handlers processing the interchange

being reported. 2 TA304 through TA3 1 1 and TA3 1 8 through TA32 1 are used to identify the interchange whose status is being reported.

3 TA312 through TA314 identify the action being reported and the date and time that action was performed. TA315 through TA317 provide a second set of interchange

action code, date and time that can be included if a given TA3 is reporting on more

than one event. 4 TA322 through TA327 contain optional information exchanged by service request handlers to supply additional information concerning actions taken upon the interchange being reported.

1. Only one interchange action may be reportedper TA3. Ifmultiple events are to be

reported, multiple TA3s must be used.

2. Only one interchange control structure error may be reported per TA3. Ifmultiple errors are to be reported, multiple TA3s must be used.

Ref. Pes. Must Use TA301

Must Use TA302

Must Use TA303

Data

Element

138

139

143

Data Element Summary

Name Attributes

Service Request Handler ID Qualifier M ID 2/2

This is a code identifying the service request handler

Cite the code FG to indicate the Federal Government Do so whether the

originator is a public or private organization.

Service Request Handler ID M AN 1/15

This is the identification code of the sending service request handler

Cite the D-U-N-S or D-U-N-S+4 ofthe service request handler providing this notice ofinterchange delivery.

Error Reason Code M ID 3/3

The code indicates the error found or not found in processing the control

structure or in delivery

000 No Errors 001 The Interchange Control Number in the Header and

Trailer Do not Match; the Value from the Header is used in the Acknowledgment

002 This Standard as Noted in the Control Standards

Identifier is not Supported

BASELINE AS OF: 28 August 1997 31
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Must Use TA304

Must Use TA305

144

145

Must Use TA306

Must Use TA307

Must Use TA308

146

147

148

003 This Version of the Controls is not Supported

004 The Segment Terminator is Invahd

005 Invalid Value as Shown in the Reported Interchange

Control Number

006 Invalid Value as Shown in the Reported Interchange Date 007 Invalid Value as Shovra in the Reported Interchange

Time

008 Invalid Value as Shown in the Reported Interchange

Sender ID Qualifier

009 Invalid Value as Shown in the Reported Interchange

Sender ID

010 Invalid Value as Shown in the Reported Interchange

Receiver ID Qualifier

011 Invalid Value as Shown in the Reported Interchange

Receiver ID

0 1 6 Trading Partnership not Established

0 1 7 Invalid Number of Included Groups Value

018 Invalid Control Structure 019 Improper (Premature) End-of-file (Transmission)

020 Duplicate Interchange Control Number

02 1 Invalid Data Element Separator

022 Invalid Component Element Separator

023 Failure to Transfer Interchange to the next Service

Request Handler

03 1 Receiver Not On-line

032 Abnormal Conditions

Reported Start Segment ID M AN 2/3

This contains the start segment ID of the original interchange, functional group

or transaction set For ANSIASCXI2 interchanges, the start segment ID is always ISA. Reported Controi Number M AN 1/14

This is the control number value of the original interchange, functional group

or transaction set Cite the control number assigned in the original interchange control header

(appearing in ISA13) for which notice is being provided. With this control

number, the TA3 is linked to the original interchange envelope.

Reported Date M AN 1/8

This is the date value of original interchange or ftmctional group

Cite the date appearing in ISA09 ofthe interchangefor which delivery notice

is being provided.

Reported Time M AN 1/8

This is the time value of original interchange or functional group

Cite the time appearing in ISAIO ofthe interchangefor which delivery notice

is being provided

Reported Interchange Sender ID Qualifier M AN 1/4

This is the sender ID qualifier value appearing in original interchange

Cite the value appearing in ISA05 ofthe interchangefor which delivery

notice is being provided.

32 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Must Use TA309

Must Use TA310

Must Use TA311

Must Use TA312

Must Use TA313

Must Use TA314

Not Used TA315

Not Used TA316

Not Used TA317

Not Used TA318

149 Reported Sender ID M AN 1/35

This is the sender ID value of original interchange or functional group

Cite the value appearing in ISA06 ofthe interchangefor which delivery

notice is being provided.

150 Reported Interchange Receiver ID Qualifier M AN 1/4

This is the receiver ID qualifier value appearing in original interchange

Cite the value appearing in ISA07 ofthe interchangefor which delivery

notice is being provided.

151 Reported Receiver ID M AN 1/35

This is the receiver ID value of original interchange or functional group

Cite the value appearing in ISA08 ofthe interchangefor which delivery

notice is being provided,

140 Action Code M ID 2/2

This is a code indicating the action taken on the interchange or functional

group by the service request handler or the receiver AK Transfer to the Next Service Request Handler has been

Acknowledged

BH Transfer to Service Request Handler not Capable of

Reporting Further Status DL Delivered Interchange by Service Request Handler

PU Purged by Interchange Receiver

RD Redirected by Service Request Handler to an Alternate Receiver as Identified in the Reference Code

RF Refused by Interchange Receiver

RJ Rejected by Service Request Handler; See Error Reason

Code for Cause

RT Retrieved Interchange by Receiver

TR Transferred to Next Service Request Handler by

Service Request Handler, but not yet Acknowledged

141 Action Date M DT 6/6

This is the UTC date when the service request handler took action on the reported interchange or functional group

Express the UTC (previously known as GMT) date in a six-position

(YYMMDD) format.

142 Action Time M TM 4/6

This is the UTC time when the service request handler took action on the reported interchange or functional group

Express the UTC (previously known as GMT) time in a four-position

(HHMM) format.

140 Action Code O ID 2/2

This is a code indicating the action taken on the interchange or functional group by the service request handler or the receiver Refer to 003070 Data Element Dictionary for acceptable code values.

141 Action Date O DT 6/6

This is the UTC date when the service request handler took action on the reported interchange or functional group

142 Action Time O TM 4/6

This is the UTC time when the service request handler took action on the reported interchange or functional group

152 First Reference ID Qualifier O AN 1/4

This is the ID qualifier appearing in original interchange

BASELINE AS OF: 28 August 1997 33
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Not Used TA319

Not Used TA320

Not Used TA321

TA322

TA323

Not Used TA324

Not Used TA325

Not Used TA326

Not Used TA327

153 First Reference ID O AN 1/14

This contains information from the original interchange, as defmed by the First Reference ID Quahfier data element

154 Second Reference ID Qualifier O AN 1/4

This contains ID qualifier information appearing in original interchange

155 Second Reference ID O AN 1/14

This contains information from the original interchange, as defmed by the Second Reference ID Qualifier data element

156 Reference Code Qualifier X ID 2/2

This is a code defming the information contained in the Reference Code data element

IfTA312 is code RD, use TA322 and TA323 to identify the organization to which the interchange was redirected. 05 ID of Alternate Receiver to which Interchange Has

Been Redirected

157 Reference Code X AN 1/35

This contains reference information exchanged between service request handlers concerning the reported interchange as defined by the corresponding

Reference Code Qualifier data element

'Cite the identifier ofthe organization to which the interchange was

redirected. The organization shall be identified via a unique identifierfrom

one ofthe sources listed as allowable codes in the ISAOS definition in section

10.6 ofthe Federal EDI Guidelines. The Data Universal Numbering System

(D-U-N-S) number and D-U-N-S +4 are the preferred identifiers. 156 Reference Code Qualifier X ID 2/2

This is a code defining the information contained in the Reference Code data element

157 Reference Code X AN 1/35

This contains reference information exchanged between service request handlers concerning the reported interchange as defined by the corresponding

Reference Code Qualifier data element

156 Reference Code Qualifier X ID 2/2

This is a code defming the information contained in the Reference Code data element

157 Reference Code X AN 1/35

This contains reference information exchanged between service request handlers concerning the reported interchange as defined by the corresponding

Reference Code Qualifier data element

34 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes: Semantic Notes:

Comments:

Notes:

GS Functional Group Header

Mandatory

1To indicate the beginning of a functional group and to provide control information

The data interchange control number GS06 in this header must be identical to the same

data element in the associated functional group trailer, GE02.

A functional group of related transaction sets, within the scope of X12 standards, consists of a collection of similar transaction sets enclosed by a functional group header and a functional group trailer.

1. Use to identify thefunctional group containing one or more related transactions.

2. Use to identify the specific implementation convention with which the transaction

sets contained within thefunctional group envelope comply.

3. The version and release ofthe GS segment must be the same as the version and

release ofthe transactions thatfollow it as specified in the Version /Release /Industry

Identifier Code (GS08).

4. The GS segment represented here is validfor version 2003.

Data Element Summary

Name Attributes

Functional Identifier Code M ID 2/2

Code identifying a group of application related transaction sets

Cite any valid code definedfor data element 479 in the ASCXI2 2003

Standards Data Element Dictionary providing a Federal implementation

convention existsfor the cited transaction set. Application Sender's Code M AN 2/12

Code identifying party sending transmission .

1. Cite the sending application 's identifier. This identifier must be unique

within the domain ofthe sending application 's translation point. Use ofa Dun and Bradstreet number (DUNS) is recommended to provide universal

uniqueness.

2. Transmit the required number ofcharacters without leading or trailing blanks. Must Use GS03 124 Application Receiver's Code M AN 2/12

Code identifying party receiving transmission

1. Cite the receiving application 's identifier. This identifier must be unique

within the domain ofthe receiving application 's translation point Use ofa Dun and Bradstreet number (DUNS) is recommended to provide universal

uniqueness.

2. Transmit the required number ofcharacters without leading or trailing blanks.

3. Ifthe group contains PUBLIC transactions, enter the literal string

Ref. Data

Des. Element

Must Use GSOl 479

Must Use GS02 142

BASELINE AS OF: 28 August 1997 35
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

I'PUBLrC'. Must Use GS04 29 Data Interchange Date M DT 6/6 Date sender generated a functional group of transaction sets.

1. Enter the UTC (previously known as GMT) date that this segment was

created,

2. Express the date in a six-position (YYMMDD) format.

Must Use GS05 30 Data Interchange Time M TM 4/4

Time (HHMM) when the sender generated a functional group of transaction

sets (local time at sender's location).

L Enter the UTC (previously known as GMT) lime thai this segment was

created.

2. Express the time in a four-position (HHMM) format.

Must Use GS06 28 Data Interchange Control Number M NO 1/9

Assigned number originated and maintained by the sender

% Originating activities may use any numbering scheme consistent with

Itheir business practices.

12. The scheme mustprovide sufficient uniqueness to identify each

functional group. The Group Control Number value, together with the

Application Sender's and Receiver's Codes, shall be unique within an

extended timeframe - such as a year. Responsible Agency Code M ID 1/2

Code used in conjunction with Data Element 480 to identify the issuer of the standard X Accredited Standards Committee X12

Version / Release / Industry Identifier Code M AN 1/12

Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used. Positions 1-3, Major Version Number; Positions 4-

6, Release Level of Version; Positions 7-12, Industry or Trade Association ID

(optionally assigned by user).

Each Federal and DoD Implementation Convention, based on an ANSIASC

XI2 transaction set, used by the government has a unique identifier specified asfollow:

Positions 1 through 6: ANSIASC X12 Version and Release

number (e.g. 003010) upon which the

IC is based.

Position 7: Organizational Scope

F = Federal

D=DOD

G = Government (transitional)

Positions 8 through 10: Transaction Set Identifier Code

(e.g. 850).

Position 11: Variant: A character used to differentiate between different

Must Use GS07 455

Must Use GS08 480

36 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

functional implementations ofthe same transaction set.

Ifthe convention is not a variant, an

underscore (_) will appear in this position.

Position 12: A sequential number starting with 0

and incremented by 1 each time the

implementation convention is revised.

BASELINE AS OF: 28 August 1997 37
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes: Semantic Notes:

Comments:

Notes:

GS Functional Group Header

Mandatory

1To indicate the beginning of a functional group and to provide control information

The data interchange control number GS06 in this header must be identical to the same

data element in the associated functional group trailer, GE02.

A functional group of related transaction sets, within the scope of X12 standards, consists of a collection of similar transaction sets enclosed by a functional group header and a functional group trailer.

1. Use to identify thefunctional group containing one or more related transactions.

2. Use to identify the specific implementation convention with which the transaction

sets contained within thefunctional group envelope comply.

3. The version and release ofthe GS segment must be the same as the version and

release ofthe transactions thatfollow it as specified in the Version /Release /Industry

Identifier Code (GS08).

4. The GS segment represented here is validfor version 3010.

Ref. Pes. Must Use GSOl

Must Use GS02

Must Use GS03

Data

Element

479

142

124

Data Element Summary

Name Attributes

Functional Identifier Code M ID 2/2

Code identifying a group of application related transaction sets Cite any valid code definedfor data element 479 in the ASCXI2 3010

Standards Data Element Dictionary providing a Federal implementation

convention existsfor the cited transaction set. Application Sender's Code M AN 2/12

Code identifying party sending transmission .

1. Cite the sending application 's identifier. This identifier must be unique

within the domain ofthe sending application 's translation point. Use ofa Dun and Bradstreet number (DUNS) is recommended to provide universal

uniqueness.

2. Transmit the required number ofcharacters without leading or trailing

hlanks.

Application Receiver's Code M AN 2/12

Code identifying party receiving transmission

/. Cite the receiving application 's identifier. This identifier must be unique

within the domain ofthe receiving application 's translation point Use ofa Dun and Bradstreet number (DUNS) is recommended to provide universal

uniqueness.

2. Transmit the required number ofcharacters without leading or trailing blanks.

38 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

Must Use GS04

ANSI ASC X12 VERSION/RELEASE 003070

J. Ifthe group contains PUBLIC transactions, enter the literal string

'PUBLIC.

29 Group Date M DT 6/6 Date sender generated a functional group of transaction sets.

i. Enter the UTC (previously known as GMT) date that this segment was

created.

Must Use GS05

2. Express the date in a six-position (YYMMDD)format.

30 Group Time M TM 4/4

Time (HHMM) when the sender generated a functional group of transaction

sets (local time at sender's location).

/. Enter the UTC (previously known as GMT) time that this segment was

created.

Must Use GS06

2. Express the time in a four-position (HHMM)format.

28 Group Control Number M NO 1/9

Assigned number originated and maintained by the sender

1. Originating activities may use any numbering scheme consistent with

their business practices.

Must Use GS07

Must Use GS08

2. The scheme mustprovide sufficient uniqueness to identify each

functional group. The Group Control Number value, together with the

Application Sender's and Receiver's Codes, shall be unique within an

extended timeframe - such as a year. 455 Responsible Agency Code M ID 1/2 Code used in conjunction with Data Element 480 to identify the issuer of the standard X Accredited Standards Committee XI

480 Version / Release / Industry Identifier Code M AN 1/12

Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used. Positions 1-3, Major Version Number; Positions 4-

6, Release Level of Version; Positions 7-12, Industry or Trade Association ID

(optionally assigned by user).

Each Federal and DoDImplementation Convention, based on an ANSIASC

X12 transaction set, used by the government has a unique identifier specified asfollow:

Positions 1 through 6: ANSIASCXI2 Version and Release

number (e.g. 003010) upon which the

IC is based.

Position 7: Organizational Scope

F = Federal

D = DOD

G = Government (transitional)

Positions 8 through 10: Transaction Set Identifier Code

(e.g. 850).

Position 11: Variant: A character used to differentiate between different

BASELINE AS OF: 28 August 1997 39
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

functional implementations ofthe same transaction set.

Ifthe convention is not a variant, an

underscore (_) will appear in this position.

Position 12: A sequential number starting with 0

and incremented by 1 each time the

implementation convention is revised.

Segment:

Usage:

Max Use: Purpose:

Syntax Notes: Semantic Notes:

Comments:

Notes:

GS Functional Group Header

Mandatory

1To indicate the beginning of a functional group and to provide control information

1 GS04 is the group date. 2 GS05 is the group time. 3 The data interchange control number GS06 in this header must be identical to the same data element in the associated functional group trailer, GE02.

1 A functional group of related transaction sets, within the scope of X12 standards,

consists of a collection of similar transaction sets enclosed by a fianctional group

header and a fiinctional group trailer.

1. Use to identify thefunctional group containing one or more related transactions.

2. Use to identify the specific implementation convention with which the transaction

sets contained within thefunctional group envelope comply.

3. The version and release ofthe GS segment must be the same as the version and

release ofthe transactions thatfollow it as specified in the Version / Release /Industiy

Identifier Code (GS08).

4. The GS segment represented here is validfor version 3040 through 3070.

Must Use

Ref. Pes. GSOl

Must Use GS02

Data

Element

479

142

Data Element Summary

Name Attributes

Functional Identifier Code M ID 2/2

Code identifying a group of application related transaction sets Cite any valid code definedfor data element 479 in the ASC XI2 3040

through 3070 (as applicable) Standards Data Element Dictionary providing

a Federal implementation convention exists for the cited transaction set. Application Sender's Code M AN 2/15

Code identifying party sending transmission; codes agreed to by trading

partners

1. Cite the sending application 's identifier. This identifier must be unique

within the domain ofthe sending application 's translation point. Use of a Dun and Bradstreet number (DUNS or DUNS+4) is recommended to provide

universal uniqueness.

40 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

2. Transmit the required number ofcharacters without leading or trailing blanks. Must Use GS03 124 Application Receiver's Code M AN 2/15

Code identifying party receiving transmission. Codes agreed to by trading

partners

1. Cite the receiving application 's identifier. This identifier must be unique

within the domain ofthe receiving application 's translation point. Use ofa Dun and Bradstreet number (D-U-N-S or D-U-N-S+4) is recommended to provide universal uniqueness.

2. Transmit the required number ofcharacters without leading or trailing blanks.

3. Ifthe group contains PUBLIC transactions, enter the literal string

'PUBLIC.

Must Use GS04 373 Date M DT 6/6 Date (YYMMDD)

L Enter the UTC (previously known as GMT) date that this segment was

created.

2. Express the date in a six-position (YYMMDD)format.

Must Use GS05 337 Time M TM 4/8

Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-

59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds

are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)

7. Enter the UTC (previously known as GMT) time that this segment was

created.

2. Express the time in a four-position (HHMM) format.

Must Use GS06 28 Group Control Number M NO 1/9

Assigned number originated and maintained by the sender

L Originating activities may use any numbering scheme consistent with

their business practices.

2. The scheme must provide sufficient uniqueness to identify each

functional group. The Group Control Number value, together with the

Application Sender's and Receiver's Codes, shall be unique within an

extended timeframe - such as a year. Must Use GS07 455 Responsible Agency Code M ID 1/2

Code used in conjunction with Data Element 480 to identify the issuer of the standard X Accredited Standards Committee X12

Must Use GS08 480 Version / Release / Industry Identifier Code M AN 1/12

Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version

number; positions 4-6 are the release and subrelease, level of the version; and

positions 7-12 are the industry or trade association identifiers (optionally

assigned by user); if code in DE455 in GS segment is T, then other formats are allowed

BASELINE AS OF: 28 August 1997 41
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Each Federal and DoD Implementation Convention, based on an ANSIASC

XI2 transaction set, used by the government has a unique identifier specified as follow:

Positions 1 through 6: ANSIASC XI2 Version and Release

number (e.g. 003010) upon which the

IC is based.

Position 7: Organizational Scope

F = Federal

D=DOD

G = Government (transitional)

Positions 8 through 10: Transaction Set Identifier Code

(e.g. 850).

Position 11: Variant: A character used to differentiate between different functional implementations ofthe same transaction set

Ifthe convention is not a variant, an

underscore (_) will appear in this position.

Position 12: A sequential number starting with 0

and incremented by I each time the

implementation convention is revised.

42 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes:

Semantic Notes:

Comments:

Notes:

SIS Security Header Level 1 Optional

1To initiate the beginning of a secured area and to provide the parameters needed for authentication or encryption of a functional group

1 If either S1S04 or SI 805 is present, then the other is required.

2 If any of S 1 806 S 1 S07 S 1 S08 or S 1 809 is present, then all are required.

1 If 81 SOI is "AA" or "BB", 81804 is required.

If SlSOl is ""BB" or "EE", 81806 is required.

1. X9 has a minimum length of4 charactersfor S1S02 (the security originator); no

mechanism, or registration method is provided by X9 or X12 to guarantee the

uniqueness ofthe identifier

2. X9 has a minimum length of4 charactersfor S1S03 (the security recipient); no

mechanism, or registration method is provided by X9 or XI2 to guarantee the

uniqueness ofthe identifier

3. The SIS segment represented here is only validfor versions 3040 and 3050.

Ref. Pes. Must Use SlSOl

Must Use S1S02

Data

Element

990

824

Data Element Summary

Name Attributes

Security Type M ID 2/2

Code identifying the security algorithms and methods employed for this level of interchange.

EE Encryption, No Authentication

Security Originator Name M AN 4/16

Unique designation (identity) of the cryptographic process that performs

authentication or encryption on data to be interchanged, or originates a cryptographic service message

Must Use SI SOS

S1S04

S1S05

Note: X9 has a minimum length of 4 characters for the security originator; no

mechanism, or registration method is provided by X9 or XI 2 to guarantee the uniqueness of the identifier 825 Security Recipient Name M AN 4/16

Unique designation (identity) of the cryptographic process that performs

authentication or decryption on received data, or is the destination of a cryptographic service message

Note: X9 has a minimum length of 4 characters for the security recipient; no

mechanism, or registration method is provided by X9 or X12 to guarantee the uniqueness of the identifier 991 Authentication Key Name X AN 1/16

Name of the key used for authentication. This name is mutually known to the security originator and the security recipient, is unique for this relationship,

and allows a particular key to be specified.

992 Authentication Service Code X ID 1/1 Authentication option

ANSI X9.9 Binary Data ANSI X9.9 Coded Character Set, Entire Message, No

Editing

BASELINE AS OF: 28 August 1997 43
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

S1S06

S1S07

993

994

S1S08

S1S09

995

996

Standard value for ANSI X9.17 authentication, with the data element separator expressed as an asterisk and the segment terminator expressed as a linefeed character for the calculation of the message authentication code

(MAC)

Encryption Key Name X AN 1/16

Name of the key used for encryption. This name is mutually known to the

security originator and the security recipient, is unique for this relationship,

and allows a particular key to be specified.

Encryption Service Code X ID 1/3

Coded values representing options for encryption processing. The code defines

the encryption mode and the transmission filter specification for filtering

binary ciphertext data into transmittable text. 2 1 ANSI X9.23 Cipher Block Chaining (CBC),

Hexadecimal Filter 22 ANSI X9.23 Cipher Block Chaining (CBC), ASCII

Filter 41 ANSI X9.23 CFB-8 (Cipher Feedback), Hexadecimal

Filter 42 ANSI X9.23 CFB-8 (Cipher Feedback), ASCII Filter Length of Data (LOD) X N 1/18

Length of data is the number of character positions of the encrypted, filtered

text. Initialization Vector (IV) X AN 16/16

The archival representation of a 64-bit value expressed in hexadecimal

notation as 16 ASCII characters from the set of characters (0..9, A..F); the 64-

bit value is used as a starting point for encryption of a data sequence to increase security by introducing cryptographic variance and to synchronize

cryptographic equipment; a new Initialization Vector (IV) shall be used for each message; the IV shall not be intentionally reused; the 64-bit binary value, not its ASCII representation, is used for the cryptographic process; in the interchange process, the resultant encrypted and filtered 64-bit IV is sent; the hexadecimal notation is the representation for archiving purposes; the IV shall be a random or pseudo-random number; when encrypted, the IV must be

decrypted using the Electronic Code Book (ECB) mode and the same key used

to encrypt the message

44 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes:

SIS Security Header Level 1 Optional

1To initiate the beginning of a secured area and to provide the parameters needed for authentication or encryption of a functional group

1 If either S 1 804 or S 1 805 is present, then the other is required. 2 If any of 8 1 806 8 1 807 8 1 808 or S 1 809 is present, then all are required. 3 If either C03204 or C03205 is present, then the other is required. 4 If either C03206 or C03207 is present, then the other is required.

Semantic Notes: 1 If 81 SOI is "AA", "BB", "AC" or "BC", then 81804 is required.

If 81 SOI is "BB", "EE", "AC" or "EC", then 81806 is required.

Comments: 1 X9 has a required minimum length of four characters for 81802 (security originator).

No mechanism, or registration method, is provided by X9 or X12 to guarantee

uniqueness of the identifier. 2 X9 has a required minimum length of four characters for SI 803 (security recipient).

No mechanism, or registration method, is provided by X9 or XI 2 to guarantee

uniqueness of the identifier. 3 In 81804, the special name "01234567890ABCDEF" is reserved for the hexadecimal

value 01234567890ABCDEF (i.e., a fixed, nonsecret value) to provide a well-known

value for data-integrity testing only. Notes: /. X9 has a minimum length of4 charactersfor S1S02 (the security originator); no

mechanism, or registration method is provided byX9 or XI2 to guarantee the

uniqueness ofthe identifier

2. X9 has a minimum length of4 charactersfor S1S03 (the security recipient); no

mechanism, or registration method is provided byX9 or XI2 to guarantee the

uniqueness ofthe identifier

3. The SIS segment represented here is only validfor versions 3060 and 3070.

Data Element Summary

Ref. Pes. Must Use SlSOl

Must Use S1S02

S1S03

Data

Element

990

824

825

Name

Security Type

Attributes

M ID 2/2

Code identifying the security algorithms and methods applied for this level of

interchange

EC No Authentication, Compression, Encryption

EE No Authentication, No Compression, Encryption

Security Originator Name M AN 1/64

Unique designation (identity) of the cryptographic process that performs

authentication or encryption on data to be interchanged, or originates a cryptographic service message

Note: X9 has a minimum length of 4 characters for the security originator; no

mechanism, or registration method is provided by X9 or X12 to guarantee the uniqueness of the identifier Security Recipient Name O AN 1/64

Unique designation (identity) of the cryptographic process that performs

authentication or decryption on received data, or is the destination of a cryptographic service message

Note: X9 has a minimum length of 4 characters for the security recipient; no

mechanism, or registration method is provided by X9 or X12 to guarantee the

BASELINE AS OF: 28 August 1997 45
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

S1S04

S1S05

S1S06

Must Use C03101

C03102

C03103

C03104

C03105

S1S07

Must Use C03201

uniqueness of the identifier 991 Authentication Key Name X AN 1/64

Name of the key used for authentication; this name is mutually known to the security originator and the security recipient, is unique for this relationship,

and is intended to allow the changing of the key from time to time

Note: The special key name "0123456789ABCDEF" is reserved for the hexidecimal value 0123456789ABCDEF (i.e. a fixed non-secret value) to provide a well-known value for data integrity testing only)

992 Authentication Service Code X ID 1/1 Authentication options

4 MD5 Hash

5 SHA Hash

C031 Encryption Key Information X

Information needed to identify or obtain the encryption key

993 Encryption Key Name M AN 1/64

Name of the key used for encryption; this name is mutually known to the

security originator and the security recipient, is unique for this relationship,

and is intended to allow the changing of the key from time to time

Note: If any of the optional fields are present, the Key Name should contain

either "PUBLIC" if a public key is being used to encrpyt the one-time key or

the actual name of the asymmetric key-encrypting-key used to encrypt the one- time key.

1564 Protocol ID O ID 3/3

Code specifying protocol used to encrypt the session key

KEA Key Encryption Algorithm

RSA RSA Algorithm

1565 Look-up Value O AN 1/512

Value used to identify a certificate containing the public key used to encrypt

the one-time key

1566 Keying Material O AN 1/512

Additional material required for decrypting the one-time key

1567 One-time Encryption Key O AN 1/512

Hexadecimally filtered encrypted one-time key

C032 Encryption Service Information X

Information required by the encryption operation

994 Encryption Service Code M ID 1/3

Coded values representing options for encryption processing, including the use of compression and filtering; the code either defines the encryption mode and

the transmission filter specification for filtering binary data into transmittable

text or specifics that the following subelements define these values

2 1 ANSI X9.23 Cipher Block Chaining (CBC),

Hexadecimal Filter 22 ANSI X9.23 Cipher Block Chaining (CBC), ASCII

Filter 4 1 ANSI X9.23 CFB-8 (Cipher Feedback), Hexadecimal

Filter

46 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

42 ANSI X9.23 CFB-8 (Cipher Feedback), ASCII Filter C03202 1568 Algorithm ID O ID 3/3

Algorithm used for Encryption

DE3 Triple DEA

DES Data Encryption Standard (Same as DEA)

As specified in FIPS 46-2. SKJ Skipjack

C03203 1569 Algorithm Mode of Operation O ID 3/3

Mode of Operation of the Encryption Algorithm

CBC Cipher Block Chaining

C03204 1570 Filter ID Code X ID 3/3

Code specifying the type of filter used to convert data code values ASB ASCII-Baudot Filter ASC ASCII Filter HDC Hexadecimal Filter UUE Uuencoding

ZZZ Mutually Defined

Use to indicate Base 64. C03205 799 Version Identifier ^ ^^^^ Revision level of a particular format, program, technique or algorithm

C03206 1571 Compression ID X ID 3/3

Type of Compression Used

913 X9E13 Compression as defined by X9.32

ZZZ Mutually Defined

Use to indicate that each block has been compressed

by using a combination ofthe Lempel-Ziv LZ77

algorithm and Huffman coding, in accordance with

the Internet Engineering Task Force (IETF) Request

for Comments (RFC) 1951 format.

C03207 799 Version Identifier X AN 1/30

Revision level of a particular format, program, technique or algorithm

Cite the version ofthe compression algorithm cited in S1S07 (C03206)

above.

51508 995 Length of Data X N 1/18

Length of data is the number of character positions of the compressed or

encrypted/filtered text; when data is plain text, this field shall be absent 51509 996 Initialization Vector X AN 16/16

The archival representation of a 64-bit value expressed in hexadecimal

notation as 16 ASCII characters from the set of characters (0..9, A..F); the 64-

bit value is used as a starting point for encryption of a data sequence to increase security by introducing cryptographic variance and to synchronize

cryptographic equipment; a new Initialization Vector (IV) shall be used for each message; the IV shall not be intentionally reused; the 64-bit binary value, not its ASCII representation, is used for the cryptographic process; in the interchange process, the resultant encrypted and filtered 64-bit IV is sent; the hexadecimal notation is the representation for archiving purposes; the IV shall be a random or pseudo-random number; when encrypted, the IV must be

BASELINE AS OF: 28 August 1997 47
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

decrypted using the Electronic Code Book (ECB) mode and the same key used

to encrypt the message

48 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment: SIS Security Header Level 2 Usage: Optional

Max Use: 1 Purpose: To initiate the beginning of a secured area and to provide the parameters needed for authentication or encryption of a transaction set Syntax Notes: 1 If either S2S04 or S2S05 is present, then the other is required.

2 If any of S2S06 S2S07 S2S08 or S2S09 is present, then all are required.

Semantic Notes: 1 If S2S01 is "AA" or "BB", S2S04 is required.

If S2S01 is "BB" or '"EE", S2S06 is required.

Comments:

Notes: 1. X9 has a minimum length of4 charactersfor S2S02 (the security originator); no

mechanism, or registration method is provided byX9 orX12 to guarantee the

uniqueness ofthe identifier

2. X9 has a minimum length of4 charactersfor S2S03 (the security recipient); no

mechanism, or registration method is provided by X9 or XI2 to guarantee the

uniqueness ofthe identifier. 3. The S2S segment represented here is only validfor versions 3040 and 3050.

Ref. Pes. Must Use S2S01

Must Use S2S02

Data

Element

990

824

Data Element Summary

Name Attributes

Security Type M ID 2/2

Code identifying the security algorithms and methods employed for this level of interchange.

EE Encryption, No Authentication

Security Originator Name M AN 4/16

Unique designation (identity) of the cryptographic process that performs

authentication or encryption on data to be interchanged, or originates a cryptographic service message

Must Use S2S03

S2S04

S2S05

S2S06

Note: X9 has a minimum length of 4 characters for the security originator; no

mechanism, or registration method is provided by X9 or XI 2 to guarantee the uniqueness of the identifier 825 Security Recipient Name M AN 4/16

Unique designation (identity) of the cryptographic process that performs

authentication or decryption on received data, or is the destination of a cryptographic service message

Note: X9 has a minimum length of 4 characters for the security recipient; no

mechanism, or registration method is provided by X9 or XI 2 to guarantee the uniqueness of the identifier 991 Authentication Key Name X AN 1/16

Name of the key used for authentication. This name is mutually known to the security originator and the security recipient, is unique for this relationship,

and allows a particular key to be specified.

992 Authentication Service Code X ID 1/1 Authentication option

993 Encryption Key Name X AN 1/16

Name of the key used for encryption. This name is mutually known to the security originator and the security recipient, is unique for this relationship,

BASELINE AS OF: 28 August 1997 49
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

S2S07 994

S2S08

S2S09

995

996

and allows a particular key to be specified.

Encryption Service Code X ID 1/3

Coded values representing options for encryption processing. The code defines

the encryption mode and the transmission filter specification for filtering

binary ciphertext data into transmittable text. 2 1 ANSI X9.23 Cipher Block Chaining (CBC),

Hexadecimal Filter 22 ANSI X9.23 Cipher Block Chaining (CBC), ASCII

Filter 4 1 ANSI X9.23 CFB-8 (Cipher Feedback), Hexadecimal

Filter 42 ANSI X9.23 CFB-8 (Cipher Feedback), ASCII Filter Length of Data (LOD) X N 1/18

Length of data is the number of character positions of the encrypted, filtered

text. Initialization Vector (IV) X AN 16/16

The archival representation of a 64-bit value expressed in hexadecimal

notation as 16 ASCII characters from the set of characters (0..9, A..F); the 64-

bit value is used as a starting point for encryption of a data sequence to increase security by introducing cryptographic variance and to synchronize

cryptographic equipment; a new Initialization Vector (IV) shall be used for each message; the IV shall not be intentionally reused; the 64-bit binary value, not its ASCII representation, is used for the cryptographic process; in the interchange process, the resultant encrypted and filtered 64-bit IV is sent; the hexadecimal notation is the representation for archiving purposes; the IV shall be a random or pseudo-random number; when encrypted, the IV must be

decrypted using the Electronic Code Book (ECB) mode and the same key used

to encrypt the message

50 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes:

Semantic Notes:

Comments:

S2S Security Header Level 2 Optional

1To initiate the beginning of a secured area and to provide the parameters needed for authentication or encryption of a transaction set

1 If either S2S04 or S2S05 is present, then the other is required. 2 If any of S2S06 S2S07 S2S08 or S2S09 is present, then all are required.

3 If either C03204 or C03205 is present, then the other is required.

4 If either C03206 or C03207 is present, then the other is required.

1 If S2S01 is "AA", "BB", "AC" or "BC", then S2S04 is required.

If S2S01 is "BB", "EE", "AC" or "EC", then S2S06 is required.

1 X9 has a required minimum length of four characters for S2S02 (security originator).

No mechanism, or registration method, is provided by X9 or XI 2 to guarantee

uniqueness of the identifier. 2 X9 has a required minimum length of four characters for S2S03 (security recipient).

No mechanism, or registration method, is provided by X9 or XI 2 to guarantee

uniqueness of the identifier. 3 In S2S04 the special name "01234567890ABCDEF" is reserved for the hexadecunal

value 01234567890ABCDEF (i.e., a fixed nonsecret value) to provide a well-known

value for data-integrity testing only. Notes: 1. X9 has a minimum length of4 charactersfor S2S02 (the security originator); no

mechanism, or registration method is provided byX9 orXll to guarantee the

uniqueness ofthe identifier

2. X9 has a minimum length of4 charactersfor S2S03 (the security recipient); no

mechanism, or registration method is provided by X9 or XI2 to guarantee the

uniqueness ofthe identifier.

3. The S2S segment represented here is only validfor versions 3060 and 3070.

Data Element Summary

Ref. Pes. Must Use S2S01

Must Use S2S02

S2S03

Data

Element

990

824

825

Name

Security Type

Attributes

M ID 2/2

Code identifying the security algorithms and methods applied for this level of

interchange

EC No Authentication, Compression, Encryption

EE No Authentication, No Compression, Encryption

Security Originator Name M AN 1/64

Unique designation (identity) of the cryptographic process that performs

authentication or encryption on data to be interchanged, or originates a cryptographic service message

Note: X9 has a minimum length of 4 characters for the security originator; no

mechanism, or registration method is provided by X9 or X12 to guarantee the uniqueness of the identifier Security Recipient Name O AN 1/64

Unique designation (identity) of the cryptographic process that performs

authentication or decryption on received data, or is the destination of a cryptographic service message

Note: X9 has a minimum length of 4 characters for the security recipient; no

mechanism, or registration method is provided by X9 or X12 to guarantee the

BASELINE AS OF: 28 August 1997 51
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

S2S04

S2S05

S2S06

Must Use C03101

C03102

C03103

C03104

C03105

S2S07

Must Use C03201

uniqueness of the identifier

991 Authentication Key Name X AN 1/64

Name of the key used for authentication; this name is mutually known to the

security originator and the security recipient, is unique for this relationship,

and is intended to allow the changing of the key from time to time

Note: The special key name "0123456789ABCDEF" is reserved for the

hexidecimal value 0123456789ABCDEF (i.e. a fixed non-secret value) to provide a well-known value for data integrity testing only)

992 Authentication Service Code X ID 1/1

Authentication options

4 MD5 Hash

5 SHA Hash

C031 Encryption Key Information X

Information needed to identify or obtain the encryption key

993 Encryption Key Name M AN 1/64

Name of the key used for encryption; this name is mutually known to the

security originator and the security recipient, is unique for this relationship,

and is intended to allow the changing of the key from time to time

Note: If any of the optional fields are present, the Key Name should contain

either "PUBLIC" if a public key is being used to encrypt the one-time key or

the actual name of the asymmetric key-encrypting-key used to encrypt the onetime key.

1564 Protocol ID O ID 3/3

Code specifying protocol used to encrypt the session key

KEA Key Encryption Algorithm

RSA RSA Algorithm

1565 Look-up Value O AN 1/512

Value used to identify a certificate containing the public key used to encrypt

the one-time key

1566 Keying Material O AN 1/512

Additional material required for decrypting the one-time key

1567 One-time Encryption Key O AN 1/512

Hexadecimally filtered encrypted one-time key

C032 Encryption Service Information X

Information required by the encryption operation

994 Encryption Service Code M ID 1/3

Coded values representing options for encryption processing, including the use of compression and filtering; the code either defines the encryption mode and

the transmission filter specification for filtering binary data into transmittable

text or specifies that the following subelements define these values

2 1 ANSI X9.23 Cipher Block Chaining (CBC),

Hexadecimal Filter

22 ANSI X9.23 Cipher Block Chaining (CBC), ASCII

Filter

41 ANSI X9.23 CFB-8 (Cipher Feedback), Hexadecimal

Filter

52 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

C03202

C03203

C03204

C03205

C03206

C03207

S2S08

S2S09

42 ANSI X9.23 CFB-8 (Cipher Feedback), ASCII Filter

1568 Algorithm ID O ID 3/3

Algorithm used for Encryption

DE3 Triple DBA

DES Data Encryption Standard (Same as DEA)

As specified in FIPS 46-2.

SKJ Skipjack

1569 Algorithm Mode of Operation O ID 3/3

Mode of Operation of the Encryption Algorithm

CBC Cipher Block Chaining

1570 Filter ID Code X ID 3/3

Code specifying the type of filter used to convert data code values

ASB ASCn-Baudot Filter

ASC ASCII Filter

HDC Hexadecimal Filter

UUE Uuencoding

ZZZ Mutually Defined

Use to indicate Base 64.

799 Version Identifier X AN 1/30

Revision level of a particular format, program, technique or algorithm

1571 Compression ID X ID 3/3

Type of Compression Used

913 X9E13 Compression as defined by X9.32

ZZZ Mutually Defined

Use to indicate that each block has been compressed

by using a combination ofthe Lempel-Ziv LZ77

algorithm and Huffman coding, in accordance with

the Internet Engineering Task Force (IETF) Request

for Comments (RFC) 1951 format.

799 Cite the version of the compression algorithm cited in X AN 1/30

S1S07 (C03206) above.

Revision level of a particular format, program, technique or algorithm

Cite the version ofthe compression algorithm cited in S2S07 (C03206)

above.

995 Length of Data X N 1/18

Length of data is the number of character positions of the compressed or

encrypted/filtered text; when data is plain text, this field shall be absent

996 Initialization Vector X AN 16/16

The archival representation of a 64-bit value expressed in hexadecimal

notation as 16 ASCII characters from the set of characters (0..9, A..F); the 64-

bit value is used as a starting point for encryption of a data sequence to increase security by introducing cryptographic variance and to synchronize

cryptographic equipment; a new Initialization Vector (IV) shall be used for

each message; the IV shall not be intentionally reused; the 64-bit binary value,

not its ASCII representation, is used for the cryptographic process; in the

interchange process, the resultant encrypted and filtered 64-bit IV is sent; the

hexadecimal notation is the representation for archiving purposes; the IV shall

BASELINE AS OF: 28 August 1997 53
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

be a random or pseudo-random number; when encrypted, the IV must be

decrypted using the Electronic Code Book (ECB) mode and the same key used

to encrypt the message

54 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes:

S2A Assurance Level 2

Semantic Notes: Comments:

Notes:

Ref. Pes. Must Use S2A01

Must Use S2A02

Must Use C03401

Optional

1To allow for multiple assurances at the ST/SE level

1 If C02804 is present, then C02803 is required. 2 If C02806 is present, then C02805 is required.

3 If C02808 is present, then C02807 is required. 4 If C028 10 is present, then C02809 is required. 5 If C028 1 2 is present, then C028 1 1 is required.

6 If C028 1 4 is present, then C028 1 3 is required.

7 If C028 1 6 is present, then C028 1 5 is required.

8 If C02818 is present, then C02817 is required.

9 If C02820 is present, then C02819 is required.

1 X9 has a required minimum length of four characters for S2A04 (security

originator). No mechanism, or registration method, is provided by X9 or X12 to guarantee uniqueness of the identifier. 2 X9 has a required minimum length of four characters for S2A05 (security recipient).

No mechanism, or registration method, is provided by X9 or XI 2 to guarantee

uniqueness of the identifier. 3 The date/time stamp may determine which of several key values apply, depending on start and expiration dates of different key values that may share the same

keyname.

4 Key distribution is performed by other means and thus only onetime keys are allowed in S2A09.

The use of particular codes and corresponding values in S2A09 is dependent on the exigencies of the various crytographic algorithms.

1. Assurance (Digital Signature) segments (S2A/SVA) are notpart ofthe control

envelope structure. When used, insert the S2A/SVA segmentpair(s) immediately

preceding the SE segment ofthe transaction setfor which assurance is being provided.

See Section 10.5.3 ofthe Federal Implementation Guidelines.

2. The S2A segment represented here is only validfor versions 3060 and 3070.

Data Element Summary

Data

Element

1432

Name Attributes

M ID 3/3

C034

1574

Business Purpose of Assurance

The stated business purpose for appending the assurance to an existing

secured-entity (whether functional group or transaction set); the codes

represent the intention of the business or application that has control over the assurance originator

ASG Authorization Signature Appropriate to this Document

CSG Authorization Co-signature Appropriate to this Document

Computation Methods M

Algorithms used to calculate an assurance Assurance Algorithm M ID 3/3

Code specifying the algorithm used to compute the assurance token

DSS Digital Signature Standard

As specified in FIPS 186. RSA RSA

BASELINE AS OF: 28 August 1997 55
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Must Use C03402

Must Use S2A03

1575

1434

Hashing Algorithm M ID 3/3

Code specifying the algorithm used to compute the assurance digest

MD5 MD5

SHA Secure hash algorithm

Domain of Computation of Assurance Digest M ID 1/2

The bounds of the text, whether contiguous or not, over which the computation

of the Assurance Token is computed using the defined methodology of

computation and any relevant Assurance Token parameters; the "body" is either a transaction set (beginning with the ST and including all segments up to the first S2A segment, but excluding any S2S segment) or functional group

(beginning with the GS and including all transaction sets up to the first SIA

segment, but excluding any SIS segment

"This Assurance" is defined as from the "S" in SIA or S2A up to and

including the data element separator preceeding the assurance digest

S2A04 1435

"Previous Assurance(s)" is defined as including the entne SIA or S2A

segment and the entire SVA that follows the included SIA or S2A

Refer to 003060 Data Element Dictionary for acceptable code values. Assurance Originator O AN 1/64

Unique designation (identity) of the cryptographic process that performs the

stated assurance on data to be interchanged

Note: X9 has a required minimum length of 4 characters for a security

originator; no mechanism, or registration method, is provided by X9 or X12 to guarantee uniqueness of the identifier S2A05 1436 Assurance Recipient O AN 1/64

Unique designation (identity) of the cryptographic process that performs

validation of the stated assurance on received data. In the absence of an Assurance Recipient all potenial receivers will often be able to validate the assurance because the cryptographic technique is based on a "public" (as opposed to "secret") technology

Note: X9 has required minimum length of 4 characters for a security recipient; no mechanism, or registration method, is provided by X9 or XI 2 to guarantee

uniqueness of the identifier S2A06 1443 Assurance Reference Number O AN 1/35

Alphanumeric reference number issued by security assurance originator for the

particular assurance in which it occurs; unique when used in combination with

security originator data element

S2A07 1437 Date/Time Reference O AN 17/25

Date/time stamp in format as follows: YYYYMMDDHHNNSSTTTZZZ+XXXX, where YYYY = 4 digit year (with

leading century), MM = month of year (01. .12), DD = day of month (01. .31), HH = hour of day in 24-hour format (00..23), NN = minutes of the hour (00-

59), SS = second of hour (00.. 59), TTT = [optional] milli-seconds (000..999),

ZZZ = [optional] three character, nominal time zone indicator (including

daylight savings time indicator) and XXXXX = 3-5 digit (including leading +

or - sign) offset of time to universal time, with three position format indicating hours-offset for whole hours, and five position format indicating hours and

56 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

minutes offset where this is necessary. For example:

S2A08

S2A09

Must Use C02801

Must Use C02802

Not Used C02803

Not Used C02804

Not Used C02805

Not Used C02806

Not Used C02807

Not Used C02808

Not Used C02809

199306152213300CDT+0930 which represents 15 June 1993, 22:13

(10:13pm), Central Daylight Time (Nominal Value "CDT"), in a time zone

that is offset + 9:30 from Universal Time (Australia)

1438 Assurance Text O AN 1/64

Any text needed to convey the name of a signatory, registration number,

certification number, or other assurance-originator defined or mutually-agreed

business text related to the specific assurance; this text is not defined for X12 ' purposes and thus functions technically as "free form text" though it may have

structure that is defined by the assurance originator, an industry group, a governmental agency, or bi-laterally between assurance originator and

assurance recipient

C028 Assurance Token Parameters O

Parameters needed to calculate the Assurance Token

1439 Assurance Token Parameter Code M ID 2/2

A code specifying the type of Assurance Token Parameter CI Certification Authority ID

EK Key Value - One-Time Key

KN Key Name

NT Notarization

OD Key-Encrypting-Key for One-Time Key

UI User ID

1442 Assurance Token Parameter Value M AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

1439 Assurance Token Parameter Code X ID 2/2

BASELINE AS OF: 28 August 1997 57
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Not Used C02810

Not Used C02811

Not Used C02812

Not Used C02813

Not Used C02813

Not Used C02814

Not Used C02815

Not Used C02816

Not Used C02817

Not Used C02818

Not Used C02819

Not Used C02820

A code specifying the type of Assurance Token Parameter 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

1439 Assurance Token Parameter Code X ID 2/2

1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter

Refer to 003060 Data Element Dictionary for acceptable code values. Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

S2A10 1440 Assurance Digest O AN 1/512

The result of the application of the hash defined in the methodology expressed

in ASCII-hex notation

1439

1442

58 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes: Semantic Notes: Comments:

Notes:

Must Use

Ref. Pes. SVAOl

Must Use SVA02

Must Use SVA03

Must Use C03301

Must Use C03302

SVA Security Value

Optional

1To provide the encoded output of a cryptographic algorithm

1. Assurance (Digital Signature) segments (S2A/SVA) are not part ofthe control

envelope structure. When used, insert the S2A/SVA segment pair(s) immediately

preceding the SE segment ofthe transaction setfor which assurance is being provided.

iSee Section 10.5.3 ofthe Federal Implementation Guidelines.

0. The SVA segment represented here is only validfor versions 3060 and 3070.

Data

Element

1570

799

C033

1572

1573

Data Element Summary

Name Attributes

Filter ID Code M ID 3/3

Code specifying the type of filter used to convert data code values ASB ASCII-Baudot Filter ASC ASCII Filter HDC Hexadecimal Filter UUE Uuencoding

ZZZ Mutually Defined

l/se to indicate Base 64. Version Identifier M AN 1/30

Revision level of a particular format, program, technique or algorithm

Security Value M

Value of the Security Token

Security Value Qualifier M ID 3/3

Type of Security Value

ASV Assurance Token

CRT Certificate Onlyfor use in the 3070 version ofthis segment.

PUB Public Key

Onlyfor use in the 3070 version ofthis segment.

Encoded Security Value M AN 1/10E16

Encoded representation of the Security Value specified by the Security Value

Qualifier

BASELINE AS OF: 28 August 1997 59
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Security Trailer Level 2 Optional

Max Use: Purpose: To end a secured area and to provide the value of cryptographically computed

authentication codes

Syntax Notes: Semantic Notes: Comments:

Notes: The S2E segment represented here is validfor versions 3040, 3050, 3060 and 3070.

Data Element Summary

Ref. Pes. Must Use S2E01

Data

Element

997

Name

Hash or Authentication Code

Attributes

M AN 1/64

The message authentication code or hash/digest generated by the authentication process; v^^hen the Data Encryption Standard (DES) algorithm is used, the field consists of 4 hexadecimal coded characters (i.e., characters from

the set 0..9, A..F), a separator character (space, or other), and 4 hexadecimally coded characters; when non-DES hashes are used, the result of

the hash is expressed as hexadecimally coded characters without spaces; when

authentication or hash is not used, this field should be filled with a non-blank

character other than the set (0..9, A..F) for the minimum length

Enter the character "Z".

60 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes:

SIA Assurance Level 1

Semantic Notes: Comments:

Notes:

Ref. Pes. Must Use SlAOl

Must Use S1A02

Must Use C03401

Optional

1To allow for multiple assurances at the GS/GE level

1 If C02804 is present, then C02803 is required. 2 If C02806 is present, then C02805 is required.

3 If C02808 is present, then C02807 is required. 4 If C02810 is present, then C02809 is required.

5 If C02812 is present, then C0281 1 is required.

6 If C028 1 4 IS present, then C028 1 3 is required. 7 If C028 1 6 is present, then C028 1 5 is required. 8 If C02 8 1 8 is present, then C028 1 7 is required.

9 If C02820 is present, then C028 19 is required.

1 X9 has a required minimum length of four characters for S1A04 (security

originator). No mechanism, or registration method, is provided by X9 or X12 to guarantee uniqueness of the identifier. 2 X9 has a required minimum length of four characters for SI AOS (security recipient).

No mechanism, or registration method, is provided by X9 or XI 2 to guarantee

uniqueness of the identifier. 3 The date/time stamp may determine which of several key values apply, depending on start and expiration dates of different key values that may share the same

keyname.

4 Key distribution is performed by other means and thus only onetime keys are allowed in SI A09.

The use of particular codes and corresponding values in S1A09 is dependent on the exigencies of the various cryptographic algorithms.

1. Assurance (Digital Signature) segments (SIA/SVA) are notpart ofthe control

mvelope structure. When used, insert the SIA/SVA segmentpair(s) immediately

preceding the GE segment ofthe groupfor which assurance is being provided. See

Section 10.5.3 ofthe Federal Implementation Guidelines.

2. The SIA segment represented here is only validfor versions 3060 and 3070.. Data Element Summary

Data

Element

1432

Name Attributes

M ID 3/3

C034

1574

Business Purpose of Assurance

The stated business purpose for appending the assurance to an existing

secured-entity (whether functional group or transaction set); the codes

represent the intention of the business or application that has control over the assurance originator

ASG Authorization Signature Appropriate to this Document

CSG Authorization Co-signature Appropriate to this Document

Computation Methods M

Algorithms used to calculate an assurance Assurance Algorithm M ID 3/3

Code specifying the algorithm used to compute the assurance token

DSS Digital Signature Standard

As specified in FIPS 186. RSA RSA

BASELINE AS OF: 28 August 1997 61
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Must Use C03402

Must Use S1A03

S1A04

S1A05

S1A06

S1A07

1575 Hashing Algorithm M ID 3/3

Code specifying the algorithm used to compute the assurance digest

MD5 MD5

SHA Secure hash algorithm

1434 Domain of Computation of Assurance Digest M ID 1/2

The bounds of the text, whether contiguous or not, over which the computation

of the Assurance Token is computed using the defined methodology of

computation and any relevant Assurance Token parameters; the "body" is either a transaction set (beginning with the ST and including all segments up to the first S2A segment, but excluding any S2S segment) or functional group

(beginning with the GS and including all transaction sets up to the first SI A

segment, but excluding any SIS segment

"This Assurance" is defined as from the "S" in SI A or S2A up to and

including the data element separator preceeding the assurance digest

"Previous Assurance(s)" is defined as including the entire SIA or S2A

segment and the entire SVA that follows the included SIA or S2A

Refer to 003060 or 003070 Data Element Dictionary, as applicable, for acceptable code values. 1435 Assurance Originator O AN 1/64

Unique designation (identity) of the cryptographic process that performs the

stated assurance on data to be interchanged

Note: X9 has a required minimum length of 4 characters for a security

originator; no mechanism, or registration method, is provided by X9 or X12 to guarantee uniqueness of the identifier 1436 Assurance Recipient O AN 1/64

Unique designation (identity) of the cryptographic process that performs

validation of the stated assurance on received data. In the absence of an

Assurance Recipient all potential receivers will often be able to validate the assurance because the cryptographic technique is based on a "public" (as opposed to "secret") technology

Note: X9 has required minimum length of 4 characters for a security recipient; no mechanism, or registration method, is provided by X9 or XI 2 to guarantee

uniqueness of the identifier 1443 Assurance Reference Number O AN 1/35

Alphanumeric reference number issued by security assurance originator for the

particular assurance in which it occurs; unique when used in combination with

security originator data element

1437 Date/Time Reference O AN 17/25

Date/time stamp in format as follows: YYYYMMDDHHNNSSTTTZZZ+XXXX, where YYYY = 4 digit year (with

leading century), MM = month of year (01.. 12), DD = day of month (01.. 31),

HH = hour of day in 24-hour format (00.. 23), NN = minutes of the hour (00-

59), SS = second of hour (00..59), TTT = [optional] milli-seconds (000..999),

ZZZ = [optional] three character, nominal time zone indicator (including

daylight savings time indicator) and XXXXX = 3-5 digit (including leading +

or - sign) offset of time to universal time, with three position format indicating

62 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

S1A08 1438

S1A09

Must Use C02801

C028

1439

Must Use C02802 1442

Not Used C02803

Not Used C02804

1439

1442

Not Used C02805

Not Used C02806

1439

1442

Not Used C02807

Not Used C02808

1439

1442

hours-offset for whole hours, and five position format indicating hours and

minutes offset where this is necessary. For example:

199306152213300CDT+0930 which represents 15 June 1993, 22:13

(10:13pm), Central Daylight Time (Nominal Value "CDT"), in a timezone that

is offset + 9:30 from Universal Time (Australia)

Assurance Text O AN 1/64

Any text needed to convey the name of a signatory, registration number,

certification number, or other assurance-originator defined or mutually-agreed

business text related to the specific assurance; this text is not defined for X12

purposes and thus functions technically as "free form text" though it may have

structure that is defined by the assurance originator, an industry group, a governmental agency, or bi-laterally between assurance originator and

assurance recipient

Assurance Token Parameters O

Parameters needed to calculate the Assurance Token

Assurance Token Parameter Code M

A code specifying the type of Assurance Token Parameter CI Certification Authority ID

EK Key Value - One-Time Key

KN Key Name

NT Notarization

ID 2/2

OD

UI

Key-Encrypting-Key for One-Time Key

User ID

Assurance Token Parameter Value M AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

BASELINE AS OF: 28 August 1997 63
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Not Used C02809 1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Not Used C02810 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Not Used C02811 1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Not Used C02812 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Not Used C02813 1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Not Used C02814 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Not Used C02815 1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Not Used C02816 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Not Used C02817 1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Not Used C02818 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

Not Used C02819 1439 Assurance Token Parameter Code X ID 2/2

A code specifying the type of Assurance Token Parameter Not Used C02820 1442 Assurance Token Parameter Value O AN 1/64

A value of a parameter, usually specifying one or more options, required for

the proper operation of the cryptographic algorithm used to compute the Assurance Token; depending on the algorithm used, one or more values may

be required

SIAIO 1440 Assurance Digest O AN 1/512

The result of the application of the hash defined in the methodology expressed

in ASCII-hex notation

64 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes: Semantic Notes: Comments:

Notes:

SVA Security Value

Ref. Pes. Must Use SVAOl

Must Use SVA02

Must Use SVA03

Must Use C03301

Must Use C03302

Optional

1To provide the encoded output of a cryptographic algorithm

1. Assurance (Digital Signature) segments (SIA/SVA) are notpart ofthe control

envelope structure. When used, insert the SIA/SVA segment pair(s) immediately

preceding the GE segment ofthe transaction setfor which assurance is being provided.

See Section 10.5.3 ofthe Federal Implementation Guidelines.

2. The SVA segment represented here is only validfor versions 3060 and 3070.

Data

Element

1570

799

C033

1572

1573

Data Element Summary

Name Attributes

Filter ID Code M ID 3/3

Code specifying the type of filter used to convert data code values ASB ASCII-Baudot Filter ASC ASCII Filter HDC Hexadecimal Filter UUE Uuencoding

ZZZ Mutually Defined

Use to indicate Base 64. Version Identifier M AN 1/30

Revision level of a particular format, program, technique or algorithm

Security Value M

Value of the Security Token

Security Value Qualifier M ID 3/3

Type of Security Value

ASV Assurance Token

CRT Certificate pnlyfor use in the 3070 version ofthis segment.

PUB Public Key

Onlyfor use in the 3070 version ofthis segment

Encoded Security Value M AN 1/10E16

Encoded representation of the Security Value specified by the Security Value

Qualifier

BASELINE AS OF: 28 August 1997 65
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Security Trailer Level 1 Optional

Max Use: Purpose: To end a secured area and to provide the value of cryptographically computed

authentication codes

Syntax Notes: Semantic Notes: Comments:

Notes: The SIE segment represented here is validfor versions 3040, 3050, 3060 and 3070.

Data Element Summary

Ref.

Pes. Must Use SlEOl

Data

Element

997

Name

Hash or Authentication Code

Attributes

M AN 1/64

The message authentication code or hash/digest generated by the authentication process; when the Data Encryption Standard (DES) algorithm is used, the field consists of 4 hexadecimal coded characters (i.e., characters from

the set 0..9, A..F), a separator character (space, or other), and 4 hexadecimally coded characters; when non-DES hashes are used, the result of

the hash is expressed as hexadecimally coded characters without spaces; when

authentication or hash is not used, this field should be filled with a non-blank

character other than the set (0..9, A..F) for the minimum length

JEnter the character "Z".

66 BASELINE AS OF: 28 August 1997
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes: Semantic Notes:

GE Functional Group Trailer

Mandatory

1To indicate the end of a fimctional group and to provide control information

1

Comments: 1

The data interchange control number GE02 in this trailer must be identical to the same data element in the associated functional group header, GS06.

The use of identical data interchange control numbers in the associated functional

group header and trailer is designed to maximize functional group integrity. The

control number is the same as that used in the corresponding header.

Must Use

Ref. Pes. GEOl

Must Use GE02

Data

Element

97

28

Data Element Summary

Name Attributes

Number of Transaction Sets Included M NO 1/6 Total number of transaction sets included in the functional group or interchange (transmission) group terminated by the trailer containing this data element

L Use to identify the number ofST segments (transactions) within a

functional group.

2. Transmit the required number ofcharacters without leading or trailing blanks. Group Control Number M NO 1/9

Assigned number originated and maintained by the sender

Cite the same group control number as was assigned by the originator in GS06.

BASELINE AS OF: 28 August 1997 67
FEDERAL GOVERNMENT

IMPLEMENTATION GUIDELINES

ANSI ASC X12 VERSION/RELEASE 003070

Segment:

Usage:

Max Use: Purpose:

Syntax Notes: Semantic Notes: Comments:

lEA Interchange Control Trailer

Mandatory

1To define the end of an interchange of zero or more functional groups and interchangerelated control segments

Must Use

Ref. Pes. lEAOl

Must Use IEA02

Data

Element

116

112

Data Element Summary

Name Attributes

Number of Included Functional Groups M NO 1/5

A count of the number of fiinctional groups included in an interchange

1. Use to identify the number of GS segments (functional groups) within an

interchange.

2, Transmit the required number of characters without leading or trailing blanks. . „ -,^.^„.;.^,w,t«,tf„ Interchange Control Number M NO 9/9

A control number assigned by the interchange sender

Cite the same nine^digit interchange control number as was assigned by the

miginator in ISA13.

68 BASELINE AS OF: 28 August 1997
I!

i

I'

I'
i

I
Technical Publications

Periodical

Journal of Research of the National Institute of Standards and Technology—Reports NIST research and development in those disciplines of the physical and engineering sciences in which the Institute is active. These include physics, chemistry, engineering, mathematics, and computer sciences. Papers cover a broad range of subjects, with major emphasis on measurement methodology and the basic technology

underlying standardization. Also included from time to time are survey articles on topics closely related to the Institute's technical and scientific programs. Issued six times a year.

Nonperiodicals

Monographs—Major contributions to the technical literature on various subjects related to the

Institute's scientific and technical activities. Handbooks—Recommended codes of engineering and industrial practice (including safety codes) devel- oped in cooperation with interested industries, professional organizations, and regulatory bodies. Special Publications—Include proceedings of conferences sponsored by NIST, NIST annual reports, and

other special publications appropriate to this grouping such as wall charts, pocket cards, and bibliographies.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical

properties of materials, compiled from the world's literature and critically evaluated. Developed under a worldwide program coordinated by NIST under the authority of the National Standard Data Act (Public

Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data (JPCRD) is published

bimonthly for NIST by the American Chemical Society (ACS) and the American Institute of Physics (AIP).

Subscriptions, reprints, and supplements are available from ACS, 1155 Sixteenth St., NW, Washington, DC

20056.

Building Science Series—Disseminates technical information developed at the Institute on building

materials, components, systems, and whole structures. The series presents research results, test methods, and

performance criteria related to the structural and environmental functions and the durability and safety

characteristics of building elements and systems.

Technical Notes—Studies or reports which are complete in themselves but restrictive in their treatment of

a subject. Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often serve as a vehicle for final reports of work performed at NIST under the sponsorship of

other government agencies.

Voluntary Product Standards—Developed under procedures published by the Department of Commerce

in Part 10, Title 15, of the Code of Federal Regulations. The standards establish nationally recognized

requirements for products, and provide all concerned interests with a basis for common understanding of

the characteristics of the products. NIST administers this program in support of the efforts of private-sector

standardizing organizations.

Order the following NIST publications—FIPS and NISTIRs—from the National Technical Information

Service, Springfield, VA 22161

Federal Information Processing Standards Publications (FIPS PUB)—Publications in this series

collectively constitute the Federal Information Processing Standards Register. The Register serves as the

official source of information in the Federal Government regarding standards issued by NIST pursuant to the Federal Property and Administrative Services Act of 1949 as amended. Public Law 89-306 (79 Stat. 1127), and as implemented by Executive Order 1 1717 (38 FR 12315, dated May 11, 1973) and Part 6 of

Title 15 CFR (Code of Federal Regulations).

NIST Interagency Reports (NISTIR)—A special series of interim or final reports on work performed by

NIST for outside sponsors (both government and nongovernment). In general, initial distribution is handled

by the sponsor; public distribution is by the National Technical Information Service, Springfield, VA 22161,

ill paper copy or microfiche form.
u

(1)

T3 o on ooI ON

ON ^ o

IK

Q c/,

— 60 . c > 2 C O h 3 « — -= "S £ c 'J .5 . O t- j= o ^

'-n_ .- « » Z « O O (2i