1. Purpose and Scope

This Standard contains the format and establishes the data contents of the Interconnect Mailbag Control Structures for use within the context of an Electronic Data Interchange (EDI) environment. This standard defines the control segments used to start and end a mailbag containing EDI data to be exchanged between two interconnecting entities. The mailbag includes zero or more interconnect acknowledgment segments and zero or more EDI data interchanges. The basic interconnect mailbag consists of an interconnect mailbag header segment (IH), the EDI data to be transmitted from one interconnect entity to another, and the interconnect mailbag trailer segment (IT). In addition, an interconnect mailbag acknowledgment segment (IA) is provided to report complete receipt and safe storage of an interconnect mailbag.

The purpose of this standard is to provide control structures and an audit mechanism to facilitate the exchange and receipt acknowledgment of EDI data between interconnecting entities. The original sender and the ultimate receiver of the data contained in the mailbag have no responsibility for creating, managing, or removing the interconnect mailbag segments. This standard is solely for use between sites acting as interconnect entities.

Delivery of data from the original sender to the ultimate receiver may require several interconnect links. It is recognized that other point-to-point data tracking mechanisms exist. The interconnect mailbag control structures are designed to stand alone in addressing a given interconnect link. The structures are in no way dependent on the types of data tracking mechanisms that may be used in links prior to or following a link that employs the interconnect mailbag control structures.

2. Referenced and Related Standards

This standard is used with the ASC X12 series of standards on electronic data interchange.

The following material is from The Internet Engineering Task Force (IETF®). The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.

The following verbatim text is from the cited document as noted immediately below.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

Key words for use in RFCs to Indicate Requirement Levels

3. Description of Use

The interconnect mailbag header and trailer segments envelope zero or more interconnect mailbag-related control segments or interchanges and perform the following functions:

• Identify the interconnect mailbag sender and receiver

• Provide control information for the interconnect mailbag

• Allow for logon and password information

The interconnect mailbag header segment is transmitted first, followed by any optional interconnect mailbag acknowledgments, followed by any interchanges, with the interconnect mailbag trailer segment following as the last segment in the mailbag.

The interconnect mailbag acknowledgment segment is used to acknowledge one interconnect mailbag header and trailer envelope. The interconnect mailbag acknowledgment segment may be used to report the success or failure of the syntactical analysis of the interconnect mailbag segments. There is no acknowledgment for a syntactically correct interconnect mailbag containing only interconnect mailbag acknowledgments, thereby preventing an endless loop of acknowledgments. The flow of the original interconnect mailbag and the corresponding interconnect mailbag acknowledgment are diagrammed in Figure 1 with increasing time down the page.

Figure 3.1 - Flow of Original Interconnect Mailbag and Corresponding Acknowledgment

The interconnect mailbag control number value in the interconnect mailbag acknowledgment segment (IA) is the same as for the interconnect mailbag header segment (IH) for which the interconnect mailbag acknowledgment was prepared. This control number serves as a link between the interconnect mailbag header and trailer and the acknowledgment of that header and trailer.

The interconnect mailbag acknowledgment does not report on the processing or delivery status of the interchange(s) in the interconnect mailbag. The interconnect mailbag acknowledgment segment serves as receipt status notification (positive or negative) from an interconnect mailbag receiver to an interconnect mailbag sender.

The interconnect mailbag acknowledgment control segments (IA) are placed after the interconnect mailbag header segment (IH) and before the first interchange or before the trailer if there are no interchanges. More than one interconnect mailbag acknowledgment segment (IA) may be placed after the interconnect mailbag header providing the interconnect mailbag sender and receiver ID values in the interconnect mailbag header segment (IH) are appropriate for the proper delivery of the acknowledgment.

Interconnect mailbags and interconnect mailbag acknowledgments are used only between interconnecting entities.

4. Terms and Definitions

X12.6 Application Control Structure contains the formal definitions of all terms related to electronic data interchange. Additional terms used in this standard are defined below.

INTERCONNECT ENTITY
Any organization that communicates EDI data with another organization where neither communicating party is responsible for processing and acting upon the semantic data (business transactions which may be contained in the mailbag).

SERVICE PROVIDER
Any process or set of processes that accepts an interchange from a sender and conveys it to a mailbox that represents the addressed receiver. Direct connections between senders and receivers involve no service providers.

RECEIPT AND SAFE STORAGE
An interconnect mailbag is received and safely stored when: (a) the control numbers in the interconnect mailbag header and trailer match; (b) the control totals listed in the interconnect mailbag trailer are consistent with the number of interconnect mailbag acknowledgments and interchanges in the interconnect mailbag; and (c) the entire interconnect mailbag has been successfully stored such that its contents can be obtained in their entirety at some later time for processing or delivery or both.

DELIVERY
An interchange is delivered when the interchange is placed in the mailbox of the receiver addressed in the interchange header segment.

MAILBOX
A protected receiving location with a unique address such that, once an interchange is placed in the mailbox of the receiver, it may only be retrieved by the receiver.

5. Interconnect Mailbag Concepts

The primary elements of this standard are three control segments intended to be used by interconnect entities for EDI management functions.

5.1 Interconnect Entities

An interconnect entity may be charged to perform some syntactic processing of the data, such as translation or conversion, on behalf of the original sender or ultimate receiver of the data. However, a key element of an entity being considered an interconnect entity is that the entity is not a participating party in any business transaction represented in the EDI data being transferred, and the entity is not transferring the EDI data to or from the original sender or the ultimate receiver. The transaction set originator and ultimate receiver will never see nor use the interconnect mailbag control segments.

An original sender or ultimate receiver whose data center acts as a sending or receiving representative (as opposed to the end processing site) for the end user division or department may elect to have their data center use the interconnect mailbag structure when exchanging EDI data with an entity that is likewise not the original sender or ultimate receiver. For such cases, the user's data center would only use the interconnect mailbag structure when exchanging data with a service provider or the data center of another user whose data center was acting as a sending or receiving representative for an end user. An internal corporate routing or network mechanism is an example of this type of end user representative. In any event, the end user would not see the interconnect mailbag.

An entity may be considered an interconnect entity in some communication exchanges and not an interconnect entity in others, depending on the nature of the party with which the data is being exchanged. For example, a service provider receiving an EDI data transmission from the original sender of the data is not considered to be an interconnect entity and would not receive interconnect mailbag segments from that sender. If, however, that same service provider transmits that EDI data to a second service provider for delivery to the ultimate receiver, both service providers would be considered to be acting as interconnect entities for that transfer.

5.2 Interconnect Mailbag Defined

The interconnect mailbag header and the interconnect mailbag trailer form the basic interconnect mailbag. The interconnect mailbag contains data to be transmitted from one interconnect entity to another interconnect entity. EDI data interchanges contained in a mailbag may be from one or more original senders and to one or more ultimate receivers. The interconnect mailbag acknowledgment provides an interconnect entity with an audit mechanism to acknowledge the complete receipt and safe storage of an interconnect mailbag.

5.2.1 The Interconnect Mailbag Header Segment (IH)

The IH segment indicates the beginning of an interconnect mailbag, establishes the version of the interconnect mailbag control structures, identifies the interconnect mailbag sender and receiver, provides control information for the interconnect mailbag, and allows for the use of a logon ID and password for the interconnect mailbag.

5.2.2 The Interconnect Mailbag Trailer Segment (IT)

The IT segment indicates the end of an interconnect mailbag, provides control information, and reports control totals for the interconnect mailbag.

5.2.3 The Interconnect Mailbag Acknowledgment Segment (IA)

The IA segment is sent by the interconnect mailbag receiver to the interconnect mailbag sender. The interconnect mailbag acknowledgment is used to perform the following functions:

• Acknowledge the complete receipt and safe storage of an interconnect mailbag

• Report the receipt of an interconnect mailbag with incomplete contents received during a communications session that ended normally at a data link protocol level

• Report the receipt of a syntactically invalid interconnect mailbag received during a communications session that ended normally at a data link protocol level

When a complete and syntactically valid interconnect mailbag is received, the following interconnect mailbag content conditions dictate whether an interconnect mailbag acknowledgment is to be returned:

• If the interconnect mailbag contains one or more interchanges, an interconnect mailbag acknowledgment must be returned.

• If the interconnect mailbag contains no interconnect mailbag acknowledgments and no interchanges, an interconnect mailbag acknowledgment may be returned.

NOTE: There is no provision to acknowledge or respond to a complete and syntactically valid interconnect mailbag containing only interconnect mailbag acknowledgments (and no interchanges). This prevents the possibility of an endless cycle of acknowledgments and responses.

When an incomplete or invalid interconnect mailbag is received during a communications session that ended normally at a data link protocol level, a negative interconnect mailbag acknowledgment must be returned regardless of the contents of the incomplete or invalid mailbag.

If a communications session terminates abnormally at a data link protocol level, an interconnect mailbag acknowledgment (IA) is not returned in response to the data received during that failed session. Furthermore, the partial file received during that failed communications session should not be processed.

The interconnect mailbag acknowledgment (IA) must be transmitted in an interconnect mailbag whose sender and receiver IDs are equal to the receiver and sender IDs, respectively, from the mailbag being acknowledged. For example, a mailbag from sender A to receiver B is acknowledged with an interconnect mailbag acknowledgment (IA) in an interconnect mailbag from sender B to receiver A.

5.2.3.1 Timing The Interconnect Mailbag Acknowledgment

When the use of an interconnect mailbag acknowledgment is appropriate, the interconnect entity issuing the interconnect mailbag acknowledgment shall transmit the acknowledgment within two hours from the time the interconnect mailbag being acknowledged was received.

If an interconnect entity transmits an interconnect mailbag containing one or more interchanges to a receiving interconnect entity, and the communications session terminates normally at a data link protocol level, the sending interconnect entity shall expect to receive an interconnect mailbag acknowledgment from the receiving interconnect entity within two hours. Failure to receive an interconnect mailbag acknowledgment for the transmitted mailbag within the agreed upon response period shall precipitate human intervention on the part of the initial sending interconnect entity to determine the status of the unacknowledged interconnect mailbag.

5.2.3.2 Interconnect Mailbag Acknowledgment Action Codes

The IA segment provides the acknowledging interconnect entity with a mechanism to indicate the action to be taken under various situations. The following defines the intent of each of these action codes:

Action Code A (Accept)
An action code equal to "A" indicates that the interconnect mailbag is received in full, safely stored, and accepted. An accept response means only that the interconnect mailbag header and trailer control numbers match, the interconnect mailbag is syntactically valid, and the interconnect mailbag trailer control totals have been verified as accurate for the received interconnect mailbag. The accept response makes no claims that the receiving interconnect entity can process the mailbag contents, recognize the addressees indicated in any interchanges in the mailbag, or is able to deliver the interchange. The accept response simply indicates the complete receipt and safe storage of the mailbag and its contents (if any).

Action Code R (Reject/Retransmit)
An action code equal to "R" indicates that one or more problems have been detected with the interconnect mailbag. The data contents (if any) of the rejected interconnect mailbag will not be processed. The interconnect entity sender of the rejected interconnect mailbag should retransmit the mailbag.

NOTE: The reject/retransmit response is used only to indicate receipt of an incomplete interconnect mailbag received via a communication session that ended normally. This type of response should not be used to indicate receipt of a partial interconnect mailbag received during a communication session that ended abnormally because the interconnect mailbag sender will be able to detect such failures during the communications session. This response is not intended to indicate the inability or unwillingness of the receiving interconnect entity to process the mailbag contents of a complete mailbag, recognize the addressees, or deliver any interchanges in the mailbag.

Action Code C (Reject/Contact)
An action code equal to "C" indicates that one or more problems have been detected with the interconnect mailbag. The nature of the problem is such that retransmission of the mailbag is unlikely to correct the problem. The data contents (if any) of the rejected interconnect mailbag will not be processed as is. The interconnect administrator from the interconnect entity issuing the reject notice will contact the interconnect administrator from the interconnect entity receiving the reject notice to resolve the problems found in the interconnect mailbag.

NOTE: This response should only be used to indicate the receipt of an invalid interconnect mailbag received via a communication session that ended normally. This response should not be used to indicate receipt of a partial interconnect mailbag received during a communication session that ended abnormally, because the interconnect mailbag sender will be able to detect such failures during the communications session. The reject response is not intended to indicate the inability or unwillingness of the receiving interconnect entity to process the mailbag contents of a complete mailbag, recognize the addressees, or deliver any interchanges in the mailbag.

The interconnect entity that receives a reject/contact response should not retransmit the mailbag in question without first resolving the appropriate issues with the interconnect entity issuing the reject. This code should be used for cases involving multiple errors for a given interconnect mailbag.

5.2.4 The Interconnect Mailbag Client Information Header Segment (IMC)

An IMC segment may precede each client information exchange block within an interconnect mailbag. Optionally, the IMC segment may not be used at all in an interconnect mailbag. When the IMC segment is used in an interconnect mailbag, the count of IMC segments in the mailbag instance must be the same as the count of interchanges specified in the interconnect mailbag trailer, else the interconnect mailbag entity must reject the mailbag.

When one or more IMC segments are present in an interconnect mailbag instance, an interconnect mailbag entity shall determine the extent of the client information exchange block by first skipping as many bytes following the IMC segment terminator as are specified in the exchange block length element found in the IMC segment. The entity will then search for a byte pattern that matches a valid IMC segment or mailbag trailer (IT) segment. The extent of the client data shall extend from the character immediately following the segment terminator of the IMC segment to the character immediately preceding the first character of the next interconnect mailbag control segment. If exchange block length is specified in the IMC segment, it is only used to direct the search for the next interconnect mailbag segment. The specified exchange block length might not specify the extent of the contained client information exchange block.

Client data information exchange blocks need not conform to the X12 or other EDI standards, and may even appear in a ciphered or compressed form, though it should then appear as filtered data represented in the graphical character set of the X12.6 standard. Failure to conform to the graphical character set of the X12.6 standard may introduce transliteration inconsistencies in the path between the original sender and the final recipient.

An interconnect mailbag entity may include IMC segment content in its rules for routing client information exchange blocks. An interconnect mailbag entity may reject individual client information exchange blocks contained in an interconnect mailbag. Rules used to accept or reject individual client information exchange blocks are outside the scope of this standard. Rules for reporting acceptance or rejection of client information exchange blocks are outside the scope of this standard.

The content of the 'block sequence' element in the IMC segment shall be numeric, starting with the value '1' for the first IMC segment, and incrementing by one for each succeeding IMC block. The content of the exchange block length element must not exceed the length of the next client information exchange block. The content of all other elements within the IMC segment is outside the scope of this standard, but may be addressed in a formal X12 guideline or technical report.

6. Interconnect Mailbag Syntax Notation

In this section the syntax for the interconnect mailbag segments is given in Backus Naur Form (BNF), described below. Other syntax elements may be found in X12.6 Application Control Structure.

6.1 Backus Naur Form (BNF) Elements Explained

Lowercase words denote syntactic constructs, which are enclosed in angle brackets. The underscore is included as a valid character. For example:

The defined construct is on the left side of a statement and is separated from the defining right side by the symbol (::=). For example:

Uppercase words are predefined labels. For example:

Lowercase words not enclosed in angle brackets denote a general class of items that are not further defined in this section of the standard. For example:

Brackets denote optional items. For example:

A repeat count range for a repeatable construct that is appended to that particular construct is added to the BNF syntax of X12.6 Application Control Structure. The range of the repeat count is /minimum:maximum/. The repeatable construct is in braces. For example, a numeric field with one to six digits could be specified as:

6.2 Interconnect Mailbag Structures

The BNF for the syntax of this standard is given below. Other syntax elements not defined here may be found in X12.6 Application Control Structure.

NOTE: <interchange_structure> is defined in X12.5 Interchange Control Structures.

6.3 Interconnect Mailbag Segments

The basic interconnect mailbag segments consist of the IH header segment and the IT trailer segment.

6.3.1 Interconnect Mailbag Header Segment

6.3.2 Interconnect Mailbag Trailer Segment

6.3.3 Interconnect Mailbag Acknowledgment Segment

The interconnect mailbag acknowledgment segment consists of the IA segment.

6.3.4 Interconnect Mailbag Client Exchange Header Segment

The interconnect mailbag client exchange header segment consists of the IMC segment.

7. Specifications for Interconnect Mailbag Control Structures

7.1 Sequence of Interconnect Mailbag Segments

The interconnect mailbag segments shall occur in the sequence shown in Figure 7.1 - Segment Sequence Diagram.

Figure 7.1 - Segment Sequence Diagram

7.2 Date and Time in the IH Segment

The dates and times used in the interconnect mailbag header segment represent the point at which the interconnect mailbag was created for initial transmission. An interconnect mailbag time code is used to identify the basis of the time that is given in the interconnect mailbag time element.

In cases where it is necessary to retransmit an interconnect mailbag, the interconnect mailbag time should not be changed from its original value when the mailbag was created. This aids the receiver in the identification of the mailbag and the determination of the age of the mailbag.

7.3 Delimiter Specifications

The delimiters for the mailbag segments are a data element separator and a segment terminator. The delimiters that shall be used in the segments of the interconnect mailbag structure (IH, IT, and IA) are as follows:

Although X12.5 Interchange Control Structures discourages the use of these characters because of the likelihood of their inclusion in data element contents, these characters are not needed in the interconnect mailbag data elements. Neither the tilde nor the asterisk conflicts with the reserve characters used by commonly implemented interconnect protocols (2780, 3780, SNA, etc.).

These delimiters apply only to the interconnect mailbag segments, not to any interchanges being transferred in the mailbag, and in no way restrict the values that may be used in the interchanges placed in the mailbag.

7.4 Interconnect Mailbag Segment Specifications

7.4.1 Data Segment Diagram Key

The format described in Figure 7.2 - Segment Key Diagram shows, in the general case, how interconnect mailbag segments are diagrammed and how reference information is provided in the diagram. It must be noted that the actual transfer of information does not include all of the reference information; only the data segment identifier characters, the delimiters, and the values for each included data element are actually transferred in the interconnect mailbag segments.

Figure 7.2 - Segment Key Diagram

7.4.2 Interconnect Control Segments

The specifications for the control segments of this standard are shown in the Segment Directory.

7.5 Interconnect Mailbag Data Element Specifications

7.5.1 Data Element Diagram Key

The format described in Figure 7.3 - Data Element Key Diagram shows, in the general case, how a data element is diagrammed and how the reference information is provided in the diagram. It must be noted that actual transfer of information does not include all of the reference information; only the values for each included data element are actually transferred in the interconnect mailbag control segments.

Figure 7.3 - Data Element Key Diagram

7.5.2 Data Element Definitions

The specifications for the data elements of this standard are shown in the Data Element Dictionary.