Csio Transmission Session Standard Options

CSIO TRANSMISSION SESSION STANDARD OPTIONS

CSIO Std.#: C110 Version: 12(i) Date: March, 2012 Status: Approved

ALL COMMENTS REGARDING THIS STANDARD SHOULD BE ADDRESSED TO:

CENTRE FOR STUDY OF INSURANCE OPERATIONS 110 YONGE STREET, SUITE 500 TORONTO, ONTARIO M5C 1T4 TABLE OF CONTENTS

DISCLAIMER: IT IS THE SOLE RESPONSIBILITY OF EACH ORGANIZATION USING THE CSIO STANDARDS TO VERIFY THE IMPLICATIONS TO/WITH THEIR TRADING PARTNERS WHEN IMPLEMENTING OR MAKING CHANGES TO THEIR EDI FUNCTIONALITY. CSIO RECOMMENDS THAT TESTING BE DONE WITH YOUR TRADING PARTNERS PRIOR TO RELEASING ANY NEW OR AMENDED IMPLEMENTATION. PLEASE REFER TO SECTION 11.1 – GENERAL RULES, OF THE C000 STANDARDS.

CSIO TRANSMISSION SESSION STANDARD - BATCH...... 4

RECORD OF AMENDMENTS...... 5

1.0 INTRODUCTION...... 6 1.1 Purpose of This Standard...... 6 1.2 How to Read This Document...... 7

2.0 THE INFORMATION TRANSFER PROCESS...... 8 2.1 General Description...... 8 2.2 ISO Open System Interconnection Reference Model...... 8

3.0 COMMUNICATIONS STRUCTURE...... 13 3.1 Environmental Assumptions...... 13 3.2 Batch Message Transmission Assumptions...... 14 3.3 Components of Session and Message Structure...... 14 3.4 Network Considerations...... 17 3.5 Acknowledgement and Error Detection...... 17

4.0 SESSION CONTROL STRUCTURE...... 17

5.0 THE BATCH COMMUNICATIONS SESSION...... 18 5.1 Definitions...... 18 5.2 Functional Phases of the Communications Session...... 19 5.3 The Session Controller...... 23 5.4 The Signon Phase...... 24 5.5 Message Transfer Process...... 28 5.6 The Signoff Phase...... 35 5.7 Restart/Recovery Procedures...... 36

6.0 GROUPS (DETAIL)...... 42 6.1 Documentation Format...... 42 Signon Group 4SOG...... 44 Signon Rejection Group 4SOR...... 52 Receive Options Control Group 4ROC...... 56 Signoff Group 4SOF...... 60 Message Acknowledgement Group 4MAK...... 63 Negative Message Acknowledgement Group 4NMK...... 66 Stream Terminator Group 4STG...... 70 Phase Terminator Group 4PTG...... 73 Control Request Group 4CRG...... 76

CSIO TRANSMISSION SESSION STANDARD – INTERNET...... 83

RECORD OF AMENDMENTS...... 84

1.0 INTRODUCTION...... 85

2.0 TRANSACTION FLOW...... 85

3.0 CSIO STANDARD TRANSMISSION MESSAGES...... 85 3.1 CSIO Data Transmission...... 85 3.2 Mail Box Delivery Notification Message...... 88 3.3 Acknowledgement Message Format...... 88

Date Release Issued Description

3.2 Jan/1992 Repaginated

1992 Jul/1992 Revision to Standards numbering

1994 Jan/1994 Incorporated portions of C210 and moved message structure definitions to C900 - Document renamed to Transmission Session Standard

2009 Mar/2009 Add Disclaimer just below the Table of Contents Heading (MR09- 009)

1.0 INTRODUCTION

1.1 Purpose of This Standard

The purpose of this document is to describe a session structure, or framework, for the electronic communication of data between independent brokers and companies within the Property and Casualty insurance industry. The structure is specifically oriented towards batch (as opposed to interactive) transmission and does not cover interactive transmission. This document attempts not to limit the designer of hardware or software systems for communications interface, but to provide guidelines relative to the implementation of broker-company data communications capability. It contains requirements for the preferred implementation of message text and transmission control elements within a data communications session. This Standard will serve to establish definitions for the characteristics of the information-carrying structure within the overall communications envelope between any two independent systems.

This Standard assumes the existence of the various data communication levels described in section 2.0, including a physical, or electrical interface, a batch oriented Character Asynchronous, Binary Synchronous, packet switched or other batch communications link protocol and possibly, a value-added communications network. The physical and link control protocols are long established defacto Standards and will not be discussed in this document except to indicate their relationship to session and message structure. Individual value-added network protocols are dependent on the specific network if any to be utilized. However, provision has been made for accommodating existing and anticipating future commercial networks. (See Section 2.2.3) In addition, the Standard will point out areas which specifically apply to the CSIO C110 Implementation Requirement.

This Standard makes a distinction between "physical" communication, logical message acceptance and application processing. Physical communications refers to that aspect of a communications session in which the content of the communications is totally immaterial to the process of sending and receiving information. Logical message acceptance and application processing, on the other hand, imply that the sender and the ultimate receiver of information must jointly be aware of at least some portion of the content. Standard No.C11O is designed primarily to deal with "physical" communication. However, there are aspects of the Standard which imply that specific units of data require special attention and must reach their intended recipient unchanged by any intermediate physical communications processing systems. The Standard deals with these where appropriate as specific exceptions to normal processing.

In Standard No.C110, the physical and logical pairs are always the same.

COMMENTARY

It is also recognized that the broker-company environment is and is likely to remain characterized by smaller, less expensive and less powerful data processing systems in agents’/brokers' offices than exist at company locations. Therefore, it will be assumed that a broker's system is required to transmit and receive information only within the limits of the capability of its characteristic hardware and software. It should be noted that any required technical translations, for instance from Asynchronous to Binary Synchronous protocol, from ASCII to EBCDIC, etc., may not be able to be performed either by companies or by a value-added network. It would be appropriate for the Broker to delay final decision of equipment purchase, until the company(s) of choice have been contacted. Brokerage systems are not expected to transmit information to or receive

The Intelligent Access Functional specifications detail the protocols required and the functions to be performed in the environment. The specifications make assumptions about certain capabilities of an broker's functional environment that are beyond the assumptions provided in this Standard.

1.2 How to Read This Document

The following sections of this Standard present the session and message structure in a top-down fashion of increasing detail. Therefore, Section 3.0 should be considered prerequisite reading for Section 4.0, Section 5.0 prerequisite reading for Section 6.0, and so on.

In addition, it should be understood that there is a relatively simple, "basic" message structure which describes the manner in which information will be delivered between agents/brokers and companies and, supplementing that structure, a series of optional components (clearly identified as such) which can be used to restart and/or recover from communication session failures. It is a measure of the flexibility of this Standard’s approach that all restart/recovery procedures are in fact optional. Note, however, that on an ad hoc basis, it is likely that a given company may want agents/brokers who wish to interface to have implemented some portions of the optional restart/recovery structure and vice versa.

More importantly, since this Standard is aimed at batch data communications between independent insurance agents/brokers and the companies they represent, as opposed to data communication in general, there are a number of instances where the Standards material presented is a reflection of either the existing or anticipated broker-company environment and, as such, may supplement, or differ from classic, or even "elegant", data processing and data communication practices.

Where it is felt that a particular Standard’s decision is a result of such environmental influences, and that an explanation would be helpful to the reader, these explanations are separated from the main text of the document by horizontal lines and the heading "Commentary".

"Commentary" is not to be interpreted as Standard’s material in terms of implementation by any party. It is solely explanatory material designed to inform the reader of the reasoning behind a particular Standard’s item.

Briefly, the following sections of this Standard are:

o Section 2.0, describes the general data communications structure within which the brokerage-company interface fits.

o Section 3.0, provides an overview of the structure of a communications session. It describes how a communications session is broken into a data communications stream, messages, transactions, and element groups.

o Section 4.0, provides a description of the session structure specified.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 7 o Section 5.0, which covers the batch communication structure and describes the various control groups which comprise both the "basic" set and the restart/recovery or "optional" control groups.

o Section 6.0, is a detailed, element-by-element, description of each control group and the specific function and content of each data element in each control group.

Readers are invited to make comments and suggest language modifications, alternatives, additions, deletions or other changes to this Standard. Where appropriate, these comments should be supported by data, references, a discussion paper or other documentation. This and other Standards developed in the CSIO Standards program should be considered "living" documents which will be revised or updated from time-to-time as required.

2.0 THE INFORMATION TRANSFER PROCESS

2.1 General Description

In order to provide an overall context for the message structure and session control procedures presented in this Standard, Section 2.0 provides a brief overview of the process by which information is transferred between two communicating computer systems. The International Standards Organization (ISO) has developed a general model for the description of data communication between distinct computer systems or a pair of terminals attached to distinct computer systems. This model, the Reference Mode for Open Systems Interconnection (OSI), provides a useful framework for the discussion of existing and proposed computer communications systems.

The message structure and session control procedures presented in this Standard correspond to only some of the functions performed by the OSI model. Section 2 presents a brief description of the OSI model together with a discussion of where within the model the message structure and session control procedures fall.

2.2 ISO Open System Interconnection Reference Model

The protocol Reference Model of Open System Interconnection of the International Standards Organization is shown in Figure 2.1. This model is organized as a series of seven layers or levels, each one built upon its predecessor. The level protocols provide the means of exchanging information between peer architectural layers of communicating data terminal equipment (user systems). Communication between adjacent architectural layers can take place by conforming to a specific interface Standard at that level. This multi-level approach provides for a separation of functions by considering each level as a separate module in order to allow for evolutionary changes to each level of interface protocols.

The process of communicating from the Application Layer of system A to the Application Layer of system B using the Application Protocol is as follows:

o Each layer of system A passes data to the layer immediately below it, adding the necessary control information, until the lowest level is reached.

o At the lowest level, there is physical communication with system B as opposed to virtual communication at the higher levels.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 8 o The data then travels from each layer of system B to the next higher level, with appropriate control information removed until the Application level is reached.

The seven levels of the OSI protocol model are described below. It should be emphasized that the proposed OSI model is, at this point in time, a first step toward international standardization of the various protocols. The protocols currently in use in Canada have levels that correspond only approximately to those of the OSI Reference Model.

ISO OPEN SYSTEM INTERCONNECTION REFERENCE MODEL

The Physical Layer is concerned with the physical transmission of raw data bits over a communications link. Some typical issues are the electrical signal representation of bits, the order and timing of bit transmission in a character, and the number and functions of pins in circuit connectors. This Session and Message Structure Standard does not address the Physical Layer.

2.2.2 The Data Link Layer

The objective of the Data Link Layer is to transform the raw transmission facility into a link that appears free of transmission errors to the next higher layer, the Network Layer. Some typical data link protocols in use are SDLC, binary synchronous (BSC), and asynchronous start/stop. This Standard does not address the Data Link Layer.

COMMENTARY

The message structure and session control structure presented in this document are independent from the underlying data link protocol. Although the data link protocol currently used today in brokerage-company communications is almost exclusively BSC, it is anticipated that other data link protocols will be utilized in the near future. The possible future offering of services to the insurance industry by value-added networks or packet-switching may impact protocol usage. Asynchronous start/stop communications with a low error rate may be used by small brokerage systems when accessing local network nodes or company systems. The extensive use of satellite circuits by the public telephone system and the rapid pace of development of communications hardware components will also impact protocol usage.

The protocols required for packet-switched networks offer options at the physical and Data Link layers. The availability of these options will depend on the access method to the network and the network supplier's implementation. The specifications for Intelligent Access define the options implemented at the physical and Data Link layers.

2.2.3 The Network Layer

The Network Layer controls the transmission of data between a user system and a private network or a value-added network part. This layer of software provides routing and billing information or other data required for the network to perform its services. This Standard provides for data commonly required by networks by means of data elements in Headers and Trailers.

COMMENTARY

It is recognized, however, that existing network architectures (IBM's Systems Network Architecture (SNA) is an example), as well as some future networks may require additional structure which is unique to the particular network. In such a case, the entire session and message structure described in this Standard is likely to be considered formatted "text" by the network (formatted to the extent that the network will understand the format and be able to apply value-added functions) within its own unique "envelope".

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 11 This is specifically the case with packet switch networks in general and the Intelligent Access implementation in particular. The network layer is referred to as the packet layer as the access method envelopes the data into data packets which are then passed across the network. The envelope is removed by the recipient after using the envelope information to verify the reliability of the information.

The reason for providing for data commonly required, or likely to be required, by networks within this Standard is to provide for the attractive possibility that some networks will not require additional structure and, thus, that agent/ broker-company implementers of this Standard will be able to utilize a virtually identical structure in both a direct brokerage-company link and in a network environment.

2.2.4 The Transport Layer

The Transport layer or host-host is a true source-to-destination or end-to-end layer. Its purpose is to relieve the next higher level of any concern with the way in which reliable and cost effective transfer of data is achieved. Some typical functions of the transport layer might be to multiplex several transport connections onto the same network connection, to create multiple network connections in order to obtain higher throughput, or to select the most cost effective network for the session.

The transport layer typically provides a virtual circuit by means of which the two user systems carry on a conversation. This Standard does not address the Transport Layer.

2.2.5 The Session Layer

In the ISO reference model, the Session Layer is the user's interface into a network. The user may be a human being using an interactive terminal or a process in a host computer system. It is with this layer that a user must interact to establish a connection with a process on another machine. Once the connection has been established, the session layer may be used to manage the data exchange in an orderly manner. The session layer validates user ID's and passwords, and other information used to control options that may be in communications service offered by the next lower layer. The session layer often provides a facility by which a group of messages or transactions can be bracketed, so that none of them are delivered to the remote user until all of them have arrived.

Most of the features of session control presented in this Standard are functionally in the Session Layer. However, the organization of the software modules in either the agency/ brokerage or insurance company system may not precisely reflect the OSI organization.

2.2.6 The Presentation Layer

The Presentation Layer performs functions that are requested sufficiently often to warrant finding a general solution for them, rather than letting each user solve the problems on their own. These functions can often be performed by library routines called by the user. Some typical examples are text compression by removing multiple blanks or encoding commonly used data such as city names, dates, or terminology common to the users, data encryption, or conversion between EBCDIC and ASCII. (See COMMENTARY, Section 1.1, Broker systems are not expected to do this type of conversion.) The message and transaction structure presented in this Standard falls within this layer. Many of the functions the OSI reference model places in the presentation level will be found at various positions in brokerage and company operating systems or application software.

The Application Layer is the highest level in the OSI model. It is the layer in which Insurance Transactions are processed.

There are several data elements contained in the Message Header Group which contain information required by the "logical" receiver of a message in order to assure proper end to end message processing. Still others are required by the applications programs which will process the message's contents. This Standard will make specific reference to all such data and describe the logic to be followed in instances where the "physical" communicating systems are not identical to the "logical" communicators. This normally occurs when a Value-Added Network is acting as a intermediary between the sender and the ultimate receiver of the information contained within a session. The network actually conducts two physical sessions, one with the sender of messages and another with their receiver.

In the Intelligent Access environment, the physical and logical communicators are always the same.

3.0 COMMUNICATIONS STRUCTURE

3.1 Environmental Assumptions

The session and message structure defined in this Standard is specifically aimed at being useful in the current agent/broker-company environment as well as in the future. Therefore, a number of assumptions have been made about the existing environment which, to one degree or another, have influenced this Standard.

The most fundamental of these assumptions is that there are today, and will continue to be in the future, a wide variety of systems and data processing capability in agents’/brokers' offices. This equipment varies from microcomputers with limited storage and programming capability to minicomputers with considerably more capability to systems which could be characterized as "host"-type environments. This Standard is intended to be independent of this environment to the extent that no assumptions have been made regarding any specific limitations or capabilities while, as the same time, it is recognized that the structure which has been defined must be capable of implementation within potentially limited capability. Another assumption made is that there are no hardware limitations at either end of the communications link regarding the physical record size which can be transmitted. In other words, the computer at either end of the link can take a stream of characters and decompose logical records into a series of physical records for processing within that system. This stream of characters will obviously, be interspersed with hardware delimiters as specified by the link control protocol use. A corresponding assumption is that logical record lengths are unlimited and can span physical block limits. It is assumed that the link control protocol used, or either hardware or software protocol emulator packages employed, will automatically "chop up" logical records into block sizes of the specific length indicated by the link control protocol.

In summary, the transmission structure described below does not cover the specific way in which it will be implemented in any given system. It is expected that various implementations will be based on the techniques employed by the implementer, the constraints imposed by the systems with which they must deal and by the software applications which are provided in the sending and receiving systems.

In a typical broker's system, transactions may be accumulated on storage as they occur throughout the day (as opposed to being transmitted as they occur). In this environment, at the close of the day, the files will consist of numbers of transactions for several companies. The data structure described in this Standard permits maximum flexibility in the way these transactions can be transmitted. The only rigid requirement is that individual transactions, or groups of transactions, for a given company must be enclosed within a message envelope. Once this has been done, however, the entire file of messages for multiple companies could be transmitted in a single communications session to a value-added network which would, possibly among other value-added functions, route and transmit individual messages to their individual addresses. In the absence of a value-added network, an individual communications session would be required for each company. The Functional Specifications for Intelligent Access assume that the latter will take place and that the agency/brokerage system will control these sessions.

It is also possible for an broker's system to transmit individual transactions as they occur and thus send single-transaction messages. It is likewise possible to transmit multiple messages to a single company. Control information allows the addressee to verify among other things, that the entire stream of messages transmitted during the communications session has in fact been received. The specific format of the control information is defined in Section 5.0.

It is assumed that a functional acknowledgement or other application level response to a received transaction will normally be transmitted in a separate communications session. This Standard does not address, but does not preclude, interface between user systems which require interactive processing at the application level. Data base inquiry or update systems and interactive data collection systems are included in this category.

3.3 Components of Session and Message Structure

Figure 3.1 shows the various components of a transmission stream which are required in the batch transmission environment.

3.3.1 Transmission Stream and Messages

Figure 3.1 shows the breakdown of a transmission stream into its information-carrying or message components. Messages, in turn, are composed of Transactions, which are the actual insurance-information carrying units.

The components of the transmission stream are designed to carry information between independent insurance agents/brokers and the companies they represent. The transmission stream itself can be thought of as a machine - to - machine physical communication. An example is a minicomputer in an agent’s/broker's office to a host computer at a company location or to an entry node of a valued-added network. A transmission stream, as shown, may contain multiple Messages.

A Message is also a "physical" communication between machines, normally the agent/broker's and company's. Note, however, that several units of information contained within the Message Header Group are required for "logical" acceptance of the message between its sender and ultimate receiver and others for subsequent processing of the transactions it contains. Although use of a packet switch network in Intelligent Access does technically involve two separate communication sessions (the sender to the network and the network to the receiver), this can be considered as one session since the protocols in the network access provide for reliability of the transmission and retransmissions in the event of compromised data and are transparent to the application.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 14 On the other hand, some brokerage systems may find it preferable to include only a single transaction in any given message and to transmit multiple messages in a batch to any given company. The structure described in this Standard provides the flexibility necessary to support either approach.

COMMENTARY

Multiple messages in a direct broker-company transmission stream will generally be used in order to facilitate restart/recovery procedures as described in Section 5.0. Other possible uses for a multiple-message stream in a direct broker-company link are: a. A company host computer could function as a switch to direct individual messages to various company locations such as a claims, branch office, etc. b. If an agent/broker system is being shared by several agencies/ brokerages, each of the sharing agencies/brokerages can address their message(s) to a company distinct from other agencies/brokerages sharing the system and yet permit a single communications session for a particular company.

Multiple messages in a transmission stream are expected to be the rule when using a value-added network. In this case, the broker can transmit all messages for all companies in a single session and have the network forward the messages to their various destinations.

COMPONENTS OF THE TRANSMISSION STREAM

The session and message control structure defined in this Standard is designed to anticipate the requirements of value-added networks. It is hoped that this structure will suffice for that purpose. It should be understood however, that additional information may be required to satisfy the communications service used. The format of these parts of the communication session will not be defined in this Standard since they are specific to individual entities. They must however, be considered a potential part of the overall "text" for a communications session.

3.5 Acknowledgement and Error Detection

Electronic Data interface in accordance with this environment assumes three levels of acknowledgement:

(1) Communications Acknowledgement: A response to the sender at the data link protocol level to indicate the status of communications validation and error detection. The format and content of this acknowledgement will depend upon the link control used and is independent of the session and message structure described in this document.

(2) Message Acknowledgement: A response to the sender during the communications session to indicate receipt of message(s) and the status of validation of message and transaction control information. Specification of message acknowledgement is part of this Standard and is defined in Section 5.0.

(3) Functional Acknowledgement: A transmission of a delayed message (an Acceptance/Rejection transaction) to the sender to indicate status of this transmission with respect to processing performed on the transaction by the receiver.

Acceptance/Rejection transactions are not included as a part of this Standard. They are defined in the Policy Processing section.

4.0 SESSION CONTROL STRUCTURE

Session control groups are data element groups whose functions are to communicate session control information between two communicating systems. They are used to transfer the information required to establish a communications session, to direct the flow of messages between the two session participants, and to terminate the session in an orderly manner. Session Control Groups are transmitted as stand-alone units outside of the transaction and message structure. These groups never appear in transactions or messages.

The following is a brief definition of each Session Control Group. Detailed definitions may be found in Section 6.0. The usage of each Session Control Group is specified in Section 5.0.

o Signon Group: The primary Session Control Group utilized in the signon procedure. Its function is to transmit the session participant’s identification and other information required for overall session control.

o Signon Rejection Group: A Session Control Group transmitted in the signon procedure to indicate that a received Signon Group contains invalid data.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 17 o Receive Options Control Group: An optional auxiliary group utilized in the signon procedure. Its function is to specify from which originating addressees, messages will be accepted in the session and to place restrictions on the amount of data that will be accepted from each addressee.

o Signoff Group: A control group used to indicate the logical termination of the session and the imminent termination of the physical communications circuit.

o Message Acknowledgement Group (MACK): A control group used to acknowledge receipt of a message and to indicate that no error was found in the message header or message trailer.

o Stream Terminator Group (STERM): A control group which is used to indicate that a flow of groups in one direction has been completed.

o Negative Message Acknowledgement Group (NMACK): A control group used to acknowledge receipt of a message and to indicate that an error was found in a message header or message trailer data element.

o Phase Terminator Group (PTERM): A control group used to indicate that one phase of the communications session has been completed.

5.0 THE BATCH COMMUNICATIONS SESSION

5.1 Definitions

A Batch Transmission Communications Session is defined to be the entire exchange of information (after having established the communications link) between any two independent computer systems within some discrete interval of time. A complete session will include all bi-directional data flow at the communications application program level from initiation to termination of the session.

The term Session Initiator refers to the Session Participant who transmits the first group of the session. This group is always a Signon Group or a Control Request Group. Before the first group is transmitted, procedures must be executed at the data link layer (and perhaps at the physical layer) in order to establish an operations data link.

The term Session Termination refers to the data link layer and physical layer-procedures required to terminate a communications session. Whenever it is specified in this Standard that a Session Par- ticipant generates a Session Termination, it is not intended that normal data link procedures be short-cut. That is, it is required that the appropriate data link protocol acknowledgement procedures for all previously transmitted and received data, be executed.

The functions described in this section are conceptually in layers above the data link protocol layer (OSI layer 2). The manner in which communication is implemented at the data link protocol level will depend not only on the line protocol (e.g. BSC, SDLC), but also on the particular device emulation by a given session participant's system (e.g. 3780, System/3) and the processing software in a given session participant's system (e.g. CICS, JES2). This Standard does not address the data link protocol layer of communications.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 18 The presentation of the communications session in this Standard addresses functions which are performed by the session protocol (layer 5) and the presentation protocol (layer 6) of the ISO reference model of Open Systems Interconnection (OSI). The term Communication Application Program or Application Program when used in this Section 5.0, refers to a software module performing a layer 5 or layer 6 function. The location of the module in a user's system depends on the organization of the operating system and communications software and will vary from system to system.

The important distinction to be made is that these terms do not apply to insurance application programs which may exist in the application layer (layer 7) of the ISO model.

During a communications session, the information which may flow between the two communicating systems may have originated from several users of one system and may be destined for several users of the other system. For example, messages may originate from several agencies/brokerages sharing a computer system. The messages may be addressed to several different insurance processing programs in a company computer system, or to several insurance company departments or branch offices serviced by that system. The Session Participants are however, the two communicating computer systems and not one of the several "users" of each system.

5.2 Functional Phases of the Communications Session

The Batch Communications Session as defined above is composed of four functional phases:

o The Control Establishment Phase. o The Signon Phase. o A series of Message Transfer Phases. o The Signoff Phase.

It is assumed that prior to the first phase, Control Establishment, the physical communications link, must be established and the required protocol handshaking performed. This handshaking is at the data link protocol level and is outside the scope of this Standard.

COMMENTARY

In a dial-up 3780 BSC environment, one session participant makes a telephone call to establish the physical communications link. One of the participants then successfully bids for the line, transmits session-oriented data as described above, and thus becomes the Session Initiator. This is usually the participant who made the telephone call. In a leased line 3780 BSC environment, the session is initiated by one of the two participants successfully bidding for the line and transmitting session-oriented data when no session is in progress.

The first functional phase, Control Establishment, provides for the session participants to each understand which participant is to control the communications session. As explained in detail in Section 5.3, the software required to act as a Session Controller is slightly different from that required to be the Session Responder.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 19 The Signon Phase, described in Section 5.4, is the phase in which each party identifies itself to the other and agrees that a communications session in which messages may be transferred can take place.

The message transfer function consists of a series of Message Transfer Phases. A Message Transfer Phase consists of a message or messages flowing in one direction and either real or implied message acknowledgement or acknowledgements flowing in the opposite direction. Message Transfer Phases always occur in pairs with the direction of message flow reversed between each transfer phase and its successor. For instance, the initial Transfer Phase of a pair may consist of an agent/broker sending messages to a company and the company sending acknowledgements. In the second half of the Transfer Phase, the flow reverses and the company transmits messages while the agent/broker acknowledges. Note that either party may transmit the PTERM (Phase Terminator) if they have no messages to transmit in a phase. A communications session must include at least one Message Transfer Phase pair. It may include several pairs.

Figure 5.2 shows two examples of a Message Transfer Phase. In the first example, party A transmits a single message to party B and party B acknowledges. In example 2, party A has two messages to transmit to party B and each message is acknowledged. Each example shows a Message Transfer Phase. Examples 3 and 4 graphically show a Message Transfer Phase pair. In example 3, both party A and party B each transmit one message and one acknowledgement; in example 4, party A transmits two messages to party B, who acknowledges them, and then party B has one message for party A, who acknowledges.

When the Batch Transmission Standard is being used in conjunction with a value added communications network, it is important to note that the Message Sequence Number (MSN) is intended to maintain the integrity of messages between two communicating systems as this is the only possible interpretation for use of the MSN.

In order to establish an audit trail for messages travelling through the network in this manner, the Network Reference Number (NRN) has been established. This number is assigned by a network upon receipt of a message and is thereafter passed, intact, through the remainder of the message's communications path. The NRN will be defined individually by each network vendor as they implement the Batch Transmission Standard.

The Signoff Phase is the one in which a communications session is terminated. Session Termination has been defined above.

COMMENTARY

In a 3780 BSC leased line environment, a Session Termination may consist of the line being in an idle state (and the session participants' communications applications program being in an appropriate state).

In a 3780 BSC dial-up environment, a Session Participant would generate a Session Termination by transmitting a BSC disconnect sequence (DLE EOT) and placing their local telephone line "on-hook". On receipt of the disconnect sequence, the other Session Participant places their local telephone line "on-hook". Some 3780 emulators currently in use in the agency/broker-company environment do not have the capability of generating a disconnect sequence on demand. In addition, some telephone companies do not terminate a telephone call until the calling party goes "on-hook". In such cases, manual procedures must be implemented in order to prevent excessive line charges.

There are variations in each of the four types of phases, and especially in the organization of the message transfer phases, depending on the choice of optional session control features. One of the purposes of the optional features is to provide the mechanisms to permit several degrees of sophistication of restart/recovery procedures. The restart/recovery mechanisms are also presented later in this section.

EXAMPLES OF A MESSAGE TRANSFER PHASE

PARTY A PARTY B

Example 1: MESSAGE (MSG)

ACKNOWLEDGEMENT (ACK)

Example 2: MSG ACK MSG ACK

EXAMPLES OF MESSAGE TRANSFER PHASE PAIRS

PARTY A PARTY B

Example 3: MSG ACK PHASE END MSG ACK PHASE END

Example 4: MSG ACK MSG ACK PHASE END MSG ACK PHASE END

5.3.1 Definition

In each communications session, one of the Session Participants exercises overall control of the session and is designated the Session Controller. The term Session Responder is used for the other Session Participant.

The Session Controller performs the following functions:

o Initiates the Signon Phase

o Initiates the first Message Transfer Phase

o Determines the number of Message Transfer Phases in the session

o Initiates the Signoff Phase in an error-free session.

The Session Controller is established by the Session Initiator through their choice of the first Phase of the communications session. If the Session Initiator is to be the Session Controller, they initiate the Signon Phase. If the other Session Participant is to be the Session Controller, then the Session Initiator initiates a Control Establishment Phase.

5.3.2 The Control Establishment Phase

The Control Establishment Phase consists of the following sequence of steps:

(a) The Session Initiator transmits a Control Request Group.

(b) The Session Answerer edits the Group Designator, Origination Machine Address, and Password data elements of the Control Request Group.

(c) If no errors are found in the edited data elements and if the Session Answerer will accept control of the session, they initiate the Signon Phase.

(d) If an error is found in a data element or if the Session Answerer will not accept control of the Session, they transmit a Control Request Rejection Group. The Error Code data element specifies the reason the group is transmitted.

(e) When a Control Request Rejection Group is received by the Session Originator, they must terminate the connection according to the procedures of the data link protocol being used.

In the current broker-company communications environment, the system initiating the communications session is the Session Controller. In nearly all cases, the brokerage system initiates the session and does not have the capability to automatically respond to a session initiation by another party. It is anticipated that, in the future, brokerage systems may have a requirement to respond to session initiations automatically. In order to lessen the impact of the software development necessary to meet such a requirement, this Standard provides for the above mechanism to transfer session control to the Session Answerer. It is expected that implementation of this mechanism will be cost-effective relative to developing the capability to act as both Session Controller and Session Responder in brokerage systems.

5.4 The Signon Phase

5.4.1 General Description

The Signon Phase is the first phase of the communications session executed by the Session Controller. It is a two-way signon requiring validation of machine address and passwords by both participants. The purpose of the procedure is to validate each Session Participant to the other and to provide information required by each participant for management of the session. The session management information includes information relating to the configuration of the communicating systems, the type of message acknowledgement to be used in the session, receive capacities of the systems, and requests for delivery of specific types of messages.

5.4.2 Signon Phase Detail

The Signon Phase is illustrated in Figure 5.4. It consists of the following sequence of steps:

(a) The Session Controller transmits a Signon Group, followed optionally by one or more Receive Options Control Groups.

(b) The Session Responder edits the Signon Group Designator, the Origination Machine Address, and Session Password data elements of the Signon Group. Additional data elements of the Signon Group and Receive Options Control Groups may also be edited by agreement between the two participants.

(c) If an error is found in a data element, the Session Responder transmits a Signon Rejection Group. The Signon Rejection Group is an image of the Session Controller's Signon Group with different values of the Signon Response Code and Error Code data elements. (The Group Designator value is, of course also different). The Signon Response Code specifies the first data element in error and the error code specifies the nature of the error. After transmitting the Signon Rejection Group, the Session Responder terminates the connection according to the procedures of the data link protocol in use.

If no errors are found in the data elements which are edited, no Signon Rejection Group is transmitted. The Session Responder transmits their own Signon Group followed, optionally, by their Receive Option Control Groups.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 24 (d) The Session Controller edits the Session Responder's Signon Group and Receive Options Control Groups. Again, at least the Signon Group Designator, Origination Machine Address and Session Password must be edited.

(e) If an error is found in a data element, the Session Controller will transmit a Signon Rejection Group and then terminate the connection according to the procedures of the data link protocol in use.

If no errors are found in the data elements which are edited, the Session Controller will begin transmission of the first Message Transfer Phase. Receipt of any Group Header other than a Signon Rejection Group Header by the Session Responder at this point indicates that the Signon Phase has been successfully concluded.

THE SIGNON PHASE

SESSION SESSION CONTROLLER RESPONDER a. Sends Signon Group followed, optionally, by Receive Options Control Groups b. Edits Session Controller's data elements c. o If error

Sends Signon Rejection Group, then terminates communications connection according to procedures of the data link protocol in use.

o else

Sends Signon Group, followed, optionally, by Receive Options Groups. d. Edits Session Responder's data elements e. o If error

Sends Signon Rejection Group, then terminates communications connection according to procedures of the data link protocol in use.

o else

Begins the first Message Transfer Phase

Each Session Participant may specify a maximum for the amount of data to be received in the session. It is the responsibility of the responding party to assure that this limit is not exceeded. This capacity is a maximum capacity for the participating computer system and is specified by the capacity Unit Code and Capacity data elements of the participants Signon Group.

The receive capacity is the number of characters or element groups within messages that can be stored in a system. Receive capacity is calculated on the basis of uncompressed data. Receive capacity includes the capacity to receive both acceptable and unacceptable messages, implying that messages which are NMACKed (not accepted) can deplete capacity.

The minimum unit of deliverable insurance data is a message. This Standard does not support delivery of partial messages. The Additional Data Flag data elements of Message Trailer Groups and Stream Terminator Groups indicate whether messages await delivery but cannot be delivered because of capacity limitations.

5.4.4 Message Delivery Options

Messages are delivered between physically communicating pairs which may or may not be logical pairs (the sender and ultimate receiver of a message).

5.4.4.1 Matching Addressee Message Delivery

A Session Participant may limit reception of messages in a communications session to those Message Addressees for whom the participant transmitted messages. In order to use this feature the Session Participant must transmit their messages first, i.e., they must be the Session Controller. Matching Message Address delivery is specified by the value of 99 in the Receive Options Indicator of the participants Signon Group.

5.4.4.2 Selective Message Delivery Option

A Session Participant may specify that message delivery be restricted to specific Destination Message Addresses, to specific Origination Message Addresses, or to specific Destination Message Address/Origination Message Address pairs for each Destination Address designated. The maximum amount of data to be delivered for each of the above cases may also be specified.

Selective Message Delivery is specified by transmitting Receive Options Control Groups during the Signon Phase.

COMMENTARY

The selective message delivery option is intended to be used by possible future multi-user insurance agency/brokerage systems. It is expected that value-added networks will have the capability of responding to the option. It is also expected, but not required, as part of this Standard, that insurance company systems will be able to respond to the option.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 27 Insurance agency/brokerage systems are not required to respond to any message selection criteria other than system receive capacity. The more complex criteria described above are intended for the "special case", and are expected to be the exception rather than the rule.

5.5 Message Transfer Process

Transfer of messages between the Session Participants is accomplished in Message Transfer Phases. As defined in Section 5.2, a Message Transfer Phase (MTP) is a part of the message transfer process in which all messages flow in the same direction. Session control groups, however, may be transmitted in both directions during one Message Transfer Phase.

The term Message Transmitter refers to the Session Participant who is transmitting messages during a Message Transfer Phase and the term Message Receiver refers to the other Session Participant. Message Transfer Phases occur in pairs. The Message Transmitter of the first MTP of the pair is always the Session Controller. The direction of message flow reverses from one MTP to the next. Thus, the roles of the Message Transmitter and Message Receiver are reversed as one MTP ends and the next MTP begins.

The number of Message Transfer Phase Pairs (MTPPs) in a session is variable but is normally at least one. The number of MTPPs is determined by the Session Controller. After the completion of an MTPP, the Session Controller may start another MTPP or they may initiate a Signoff Phase.

If the Message Transmitter for a Message Transfer Phase does not wish to send messages in that MTP, they transmit only a Phase Terminator Group.

5.5.1 Message Acknowledgement Options

Three types of Message Acknowledgements are provided, varying from data acknowledgement only (at the data link protocol level) up to communications application program acknowledgement of each message. The type of Message Acknowledgement employed between a pair of Session Participants is normally determined by contractual agreement between the two parties. The confirmation of the correct Message Acknowledgement option is accomplished during the Signon Phase by means of the Message Acknowledgement option data element in the Sign-on Group. The message acknowledgement options provide information for audit trails and input to manual and automatic recovery-restart procedures.

Note that both halves of a Message Transfer Phase pair must use the same option.

5.5.1.1 Option A

Option A provides for no Message Acknowledgement at the communications application program level. All transmission acknowledgements are at the data link protocol level. This option is specified by a zero value of the Message Acknowledgement Option data element. No transmission checkpoints are used.

An Option A Message Transfer Phase is illustrated in Figures 5.2 and 5.6. All groups flow from the Message Transmitter to the Message Receiver. The MTP consists entirely of a sequence of messages, with the last message followed by a Phase Terminator Group (PTERM).

The second half of the Message Transfer Phase pair is identical in construction but in the opposite direction.

Message Acknowledgement Option A

Message MSG MSG MSG ... MSG PTERM Transmitter

Message (sends no groups) Receiver

COMMENTARY

It is likely that some individual participants may find use of Option A an inadequate procedure because of its limited capability for restart/recovery while others may consider its simplicity and ease of implementation to be the overriding factors.

5.5.1.2 Option B

Option B provides for a single acknowledgement of the messages received in the Message Transfer Phase. The Message Transmitter sends all their messages in the MTP followed by a STERM. The Message Receiver may edit the count fields of the STERM. They then transmit a STERM to the Message Transmitter. An Emergency Signoff Phase may be issued if an error is found in the following data elements:

o An error in the count fields (STG0l or STG02) of the Stream Terminator Group

o An error in the Message Sequence Number of the Message Header Group

If there are no errors, the Message Transmitter then sends a PTERM to the Message Receiver to indicate the reception of the Message Receiver's STERM and to terminate the Transmission Phase.

Option B is specified by a value of 9999 of the Message Acknowledgement Option of the Signon Group. A Transmission Phase in which Option B is used is illustrated in Figures 5.3 and 5.6.

Message Acknowledgement Option B

Message MSG MSG ... MSG STERM PTERM Transmitter

Message STERM Receiver

COMMENTARY

Option B is considered an "intermediate" level of acknowledgement which some participants may find an adequate compromise between Option A and the more complex, secure, but correspondingly difficult to implement, acknowledgement Option C which follows.

5.5.1.3 Option C

Option C provides for a communications applications program level acknowledgement of each message transmitted. The acknowledgement is accomplished by the Message Receiver transmitting a Control Group for each message received. Messages are transmitted in units, called Message Streams, with a specified number (N) of messages in each Message Stream. Each Message Stream, with the possible exception of the last one in the Message Transfer Phase, will contain the same number of messages.

The Message Receiver will determine that a Message Stream has been received by counting messages. There is no application level termination of a Message Stream, with the exception that the last Message Stream is always terminated by the transmission of a Stream Terminator Group. If the number of messages transmitted in the Message Transfer Phase is exactly divisible by N, then the last Message Stream will consist only of the Stream Terminator Group.

COMMENTARY

There may be a data link protocol termination of each Message Stream, depending on the protocol. For example, if BSC is used, the Message Transmitter must release the line after transmitting each Message Stream so that the Message Receiver may transmit message acknowledgements.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 31 When a Message Stream has been received, the Message Receiver transmits the message acknowledgements for the messages in the Message Stream. The message acknowledgements are transmitted in the same order as their corresponding messages.

The number (N) of messages in each Message Stream may range from 1 to 8999 and is specified by assigning that value to the Message Acknowledgement Option data element in the Signon Group. If N is larger than the number of messages transmitted, there will be only one Message Stream. A value of 9998 for the Message Acknowledgement Option data element is used to deliberately represent a number larger than the number of messages to be transmitted. Thus, if 9998 is specified as the Message Acknowledgement Option, all messages will be transmitted in one Message Stream, regardless of their number.

Option C is illustrated in figures 5.4, 5.5, and 5.6.

Figure 5.4

Message Acknowledgement Option C for N = 9998

Message MSG MSG ... MSG STERM Transmitter PTERM

Message MACK MACK ... MACK STERM Receiver

Figure 5.5

Message Acknowledgement Option. C for N = 2

Message MSG MSG ... MSG MSG MSG STERM Transmitter PTERM

Message MACK MACK MACK MACK MACK STERM Receiver

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 32 One function of the Message Acknowledgement is to inform the Message Transmitter that the message has been accepted or rejected by the receiving communications application program. Acceptance consists of locating and identifying the Message Header and the Message Trailer and editing certain data elements in those two groups. Note that in order to identify the start of a message, each successive group header may be located by use of the Group Length data element of the preceding group.

The Total Data In Message field in the Message Trailer Group must be verified by the Message Receiver as part of the Message acknowledgement function.

Each Message Acknowledgement is one of two control groups: A Message Acknowledgement Group (MACK) is transmitted to indicate a positive acknowledgement and a Negative Message Acknowledgement Group (NMACK) is transmitted to indicate a negative acknowledgement. The MACK contains data elements which uniquely identify the message being acknowledged to the Message Transmitter.

The NMACK is an image of the Message Header Group of the message being acknowledged. The values of all data elements are the same as in the received message, except for the group Designator and the Message Response Code and Error Code data elements. The Message Response Code specifies the first edited data element found to be in error. The Error Code specifies the type of error.

In all cases the sender of a message is responsible for that message until a MACK has been received. That is, they must save (or be able to reconstruct) the message until they know the receiver has MACKED it. Once the message has been MACKED, the receiver takes over responsibility for it.

If the sender of a message receives an NMACK, they remain responsible for that message and for the handling of the NMACK. An NMACK may not be issued for any errors other than the ones itemized below unless the "physically" communicating pair is the same as the "logically" communicating pair.

o The machine’s address portion of the Origination Message Address (in direct link communications only)

o The message sequence number of the Message Header Group

o The count data elements of the Message Trailer Group

If the NMACK was issued for an error in a data element other than those listed above, the responsibility for the message and the handling of the NMACK is to be negotiated between the communicating Session Participants.

If a message is NMACKED for a message sequence number error, all subsequent messages transmitted by the Session Participant who transmitted that message, will be acknowledged by NMACKS which indicate the same error. The alternative is to initiate an Emergency Signoff Procedure upon receipt of a message which contains a message sequence number error.

If a Control Group Designator is in error, the Message Receiver will initiate an Emergency Signoff Procedure.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 33 A Message Transfer Phase starts with the transmission of the first Message Stream and continues with transmission of alternating acknowledgement transmissions and Message Stream transmissions until the last Message Stream in the MTP has been transmitted. As mentioned previously, the last Message Stream is terminated with the transmission of a Stream Terminator Group (STERM).

Receiving the STERM indicates to the Message Receiver that the last Message Stream contains a short count of messages and that the next transmission will be a PTERM.

The Message Receiver then transmits the message acknowledgements for the last Message Stream and follows them by a STERM.

After receiving the Message Receiver's STERM, the Message Transmitter sends a PTERM to the Message Receiver. The PTERM notifies the Message Receiver that the Message Transmitter has received the Message Receiver's STERM and that the Message Transfer Phase has been completed.

5.5.1.4 Count Verification Feature

An optional Count Verification Feature is provided. Use of this feature is normally determined by contractual agreement between the two communication parties. Its use is specified via the Count Verification Indicator in the Signon Group. The feature does not apply to Option A or C.

The STERM transmitted by each Session Participant in a Message Transfer Phase contains data elements specifying the total data transmitted and the total number of messages or message acknowledgements, as applicable, transmitted by the Session Participant in the MTP. The total data includes the characters in the STERM. It does not include data link protocol control characters or other characters, if any, which are considered to be transparent to the message group structure of this Standard.

On receipt of the Message Transmitter's STERM, the Message Receiver may edit the Total Data in Phase and Total Messages data elements against their accumulations. The Stream Terminator Response Code of the Message Receiver's STERM may be used to indicate a disagreement to the Message Transmitter. In this case, the Message Receiver may initiate an Emergency Signoff after transmitting the STERM.

Figure 5.6 (a)

Message Acknowledgement Option A

Message MSG MSG MSG ... MSG PTERM Transmitter

Message (sends no groups) Receiver

Message Acknowledgement Option B

Message STERM Receiver

Figure 5.6 (c)

Message MACK MACK ... MACK STERM Receiver

Figure 5.6 (d)

Message MSG MSG ... MSG MSG MSG STERM PTERM Transmitter

Message MACK MACK MACK MACK MACK STERM Receiver

It is implied that use of the Count Verification Feature in Message Acknowledgement Option B, means that messages cannot be submitted for processing by the receiver's application system until the receiver is sure that they have accurately and completely received all of the messages in that stream.

Any other action on the receiver's part, could bring about a situation where a message has been processed with an intermediate level (before the stream is completed) only to find that the two communicants disagree on the count verifications in their respective STERMS. This would be an intolerable situation and must be avoided, as described above, if the Counter Verification Feature is used.

On receipt of the Message Receiver's STERM, the Message Transmitter may edit the Total Data in Phase and Total Messages data elements. The Total Messages data element, if used, will contain the number of message acknowledgements the Message Receiver has transmitted in the MTP. If the counts do not match their accumulations, the Message Transmitter should indicate the error by initiating an Emergency Sign-off.

5.6 The Signoff Phase

5.6.1 Normal Signoff Phase

The Signoff Phase is a two-way signoff requiring a transmission by both Session Participants. The function of the Signoff Phase is to provide for an orderly shutdown of the communications session at the communications applications program level. The Signoff Initiator initiates the Signoff Phase by transmitting a Signoff Group and the Signoff Answerer responds by also transmitting a Signoff Group A Signoff Phase is required in all cases before the generation of a Session Termination.

The following sequence of steps constitutes the Normal Signoff Phase:

o The Signoff Initiator transmits a Signoff Group. The Signoff Group is the last group transmitted by that Session Participant. It informs the other Session Participant, the Signoff Receiver, that a Session Termination is imminent.

o The Signoff Receiver transmits a Signoff Group to the Signoff Initiator. This is the only valid response by the Signoff Receiver.

o After the Signoff Initiator receives any transmission from the Signoff Receiver, they then initiate a Session Termination.

o If the Signoff Initiator receives no response from the Sign-off Receiver within a specific period of time, the Signoff Timeout Period, they initiate a Session Termination. The duration of the Signoff Timeout Period is established on an individual user basis.

In the absence of an error condition, a communications session is terminated by the Session Controller after the completion of a Message Transfer Phase Pair. The Session Controller always initiates the Signoff Phase for a normal session termination.

The communications session may be terminated prior to its normal completion under certain conditions by either Session Participant. The Signoff Phase employed under these circumstances is called an Emergency Signoff. It is distinguished from a Normal Signoff by the value of the Signoff Type data element of the Signoff Initiator's Signoff Group, and the fact that the Signoff Receiver makes no response to the Signoff Initiator upon receiving the Signoff Group.

An Emergency Signoff may be initiated during the Message Transfer Procedure at the following points:

o The current Message Transmitter may initiate an Emergency Signoff by transmitting a Signoff Group when they would otherwise transmit a Message Header Group, a STERM, or a PTERM.

o The current Message Receiver may initiate an Emergency Sign-off when they would otherwise transmit a MACK, a NMACK, or a STERM.

o Either Session Participant may initiate an Emergency Signoff in case of a communications application program timeout. Such a timeout occurs if the communications session is apparently active at the data link protocol level but an expected transmission is not received within the communications program timeout period. The duration of this period is to be established on an individual basis.

o If the Count Verification Feature of Message Acknowledgement Option B is implemented, an Emergency Signoff Phase may be initiated for the error conditions specified in Section 5.5.2.4.

For Restart/Recovery purposes, an Emergency Signoff has the same effect as a communications line failure at the point the Signoff Phase is initiated.

5.7 Restart/Recovery Procedures

5.7.1 Introduction

The Restart/Recovery Procedures described below are designed for three basic purposes:

o To assure that no messages transmitted between Session Participants are lost.

o To assure that no duplicate messages are transmitted without the receiver of a message being fully advised that a message might be a duplicate.

o To permit a participant, optionally, to avoid re-transmitting messages which they knows have been successfully received prior to the advent of a session abort.

The specific procedure employed between a pair of Session Participants must be determined by the message acknowledgement option selected (as described in Section 5.5) by prior agreement between the Session Participants.

All restart/recovery procedures are based on recognizing the requirement for re-transmission of either a complete session, a Message Transfer Phase, or partial Message Transfer Phase.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 37 C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 38 o Message Acknowledgement Option A is, in effect, an example of an entire communications session being composed of a single message transfer phase pair. In the event of a session abort at any point during the session, the entire session must be re-transmitted since message transmitters have no way of assuring that their messages have been received short of the successful completion of the session.

o Option B, as described in Section 5.5 allows participants to avoid, optionally, re-transmitting message transfer phases which have been successfully completed prior to the session abort.

o Participants having selected message acknowledgement Option C are given the ability to avoid re-transmitting any portion of a message transfer phase which has been successfully completed prior to a session abort.

Thus, restart/recovery procedures are based on the principle that re-transmission must occur for whatever portion of a communications session is not known to have been completed successfully. Successful completion of any portion of a session is defined to mean that the transmitter knows that receiver has successfully received their transmission. As described above, the message acknowledgement options described in Section 5.5 allow users of Option C to know whether or not individual messages have been received successfully, users of Option B to know whether or not a Message Transfer Phase has been received successfully and users of Option A to know only whether or not an entire session has been completed successfully.

Since Restart/Recovery is concerned with the integrity of messages, sessions need be recovered, if they fail during a Message Transfer Phase. Sessions that abort or are discontinued during Signon or Normal Signoff Phases need not be recovered.

When a communications session is aborted both parties will promptly set the value of the Session Restart Flag in their respective Signon Group to indicate a phase restart in the restarted session.

RESTART/RECOVERY EXAMPLES

SESSION SESSION CONTROLLER RESPONDER

Message Transmitter Message Receiver

(First Phase) (First Phase)

1. MSG #1 2. MSG #2 3. MSG #3 4. MACK (MSG #1) 5. MACK (MSG #2) 6. MACK (MSG #3) 7. MSG #4 8. MSG #5 9. STERM 10. MACK (MSG #4) 11. MACK (MSG #5) 12. STERM 13. PTERM

Message Receiver Message Transmitter

(Second Phase) (Second Phase)

14. MSG #362 15. MSG #363 ------(Etc.)

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 40 Referring to figure 5.7, a Message Transfer Phase is indicated by items 1 through 13. The Message Transmitter knows that the phase has been successfully completed when they receive message #362 (Item #14) from the Message Receiver. A message transmitter becomes a receiver just prior to sending a PTERM. This is true, regardless of whether or not they receive the required response. Some examples of restart/recovery philosophy using figure 5.7 as a reference, are:

a. If the session is aborted during transmission of message 3, the Message Transmitter, having received no indication that any messages have been received, must re-transmit beginning with the start of the Message Transfer Phase.

b. If the session is aborted during transmission of the MACK for message 3 (item 6 in figure 5.7), the Message Transmitter, having received MACKs for messages 1 and 2, has the option of beginning re-transmission with message 3 in the restated session.

c. If the Session is aborted after the Message Transmitter has sent their PTERM (item 13) but before they have received message 362 (item 14) from the receiver, the Message Transmitter, will consider themselves a receiver and await data. If the original receiver received the PTERM they will now be in a transmit mode and begin to transmit messages, starting with MSG#362. If they did not receive the PTERM they will still consider themselves a receiver. However, when they receive the transmitter's PTERM, in the restarted session, they will then switch mode to transmitter and begin to transmit messages, starting with MSG#362.

d. If, in the situation described above, the receiver having switched modes had no messages to transmit, they would transmit a PTERM of their own, concluding the restarted session. This situation, in which neither participant in a restarted session has messages to transmit results in a restart session with no data exchanged, a "null" session. This circumstance will happen infrequently.

Note that figure 5.7 is a specific example of Option C as described in Section 5.5 but also includes Options A and B as special cases of Option C and thus applies to all message transfer options.

The critical point is that a Transmitter become a receiver as soon as they send a PTERM and a receiver becomes a transmitter as soon as they receive a PTERM.

When a (restarted session) controller was the transmitter in the aborted session, they may send either message, a STERM, or a PTERM in a restarted session. If a controller believes they were the receiver, they may send only a PTERM.

When a (restarted session) responder was the transmitter in the aborted session, they may send either messages, a STERM, or a PTERM. If the responder believes they was the receiver, their action will be dictated by what they have received in the restarted session. If it was a message, they remain in normal receive mode. If it was a PTERM, they will switch to transmit mode and send messages if they have them to send. If not, they will transmit a PTERM, concluding a "null" session.

This rather complex manoeuvring allows the restart/recovery when neither party knows exactly whether or not their partner got the intended message or control group.

The procedures and examples outlined above and described in detail in the remainder of this Section 5.7, are specifically designed to provide for restart/recovery in the broker-company environment described in the following commentary.

In most data communications environment, the transmitter of messages is expected to be capable of re-transmitting a given message until they know it has been successfully received. Since the transmitter must be alert to the possibility that the original message was in fact received even though he, the transmitter, are not aware of that fact, it is often prudent for all re-transmission of a message to be marked by the transmitter as "duplicates". This provides the message receiver with two options. They may choose to process messages as they are received and be prepared to "throw away" messages marked "duplicate" if they have already been processed, or they may choose to suspend processing of messages they receive until they, the receiver, knows that the transmitter knows that they have been received and that they will thus not re-transmit the message. This process depends on the Message Transmitter being able to guarantee that any messages re-transmitted are exact duplicates of the original message. If this were not so, the Message Receiver would have no option but to suspend processing because there would be no way to "throw away" messages since they may not be exact duplicates of the original which been processed. In the existing broker-company environment, there are systems, particularly brokerage systems, that construct messages "on the fly" from their data bases and are not in a position to guarantee that re-transmitted messages are exact duplicates of the message which was being transmitted when the communications session was aborted. There are, of course, other systems which do have that capability.

If the Message Transmitter cannot guarantee re-transmission of exact duplicate messages, the Message Receiver must suspend all messages received until they know that the transmitter is aware of the fact that they have been received and thus not re-transmit the given message. There is no alternative if message integrity is to be maintained.

A flag has been provided in the Signon Group called a Recovery Type Flag to indicate whether or not the session participant is capable of guaranteeing that re-transmitted messages will be exact duplicates of the messages in the aborted communications session. The restart/recovery procedures described overleaf have been designed to be identical under either circumstance. The only difference will be in the processing required by the message receiver's system. In one case, messages may be processed as they are received while in the other, messages must be suspended until

the receiver knows that the Message Transmitter is aware of the fact that a message has in fact been received successfully.

The above philosophy has been implemented in the following set of rules.

5.7.2 Definitions and Rules

The following definitions and rules are applicable to the message delivery process and restart/recovery procedures.

A communications session is considered to be established if the first Message Transfer Phase has begun. An established communications session is defined to have been aborted if any of the following conditions occur before the Session Responder has received the Session Controller's normal Signoff Group.

b. Either Session Participant initiates an Emergency Signoff as a result of a communications program timeout, reception of unrecognizable data, or any other reason.

A Message Transfer Phase is defined to be aborted if the communications session is aborted at any point after the Message Transmitter for the MTP has started transmitting their first message and before they have received a valid response to transmission of their PTERM. The following rules apply to the restart/recovery procedure.

o If a communications session is aborted, the next session between the two Session Participants will be a restart session.

o The Session Initiator for the aborted session is responsible for seeing to it that the restart session is initiated. The Session Controller for the aborted session will be the Session Controller for the restart session.

o Either Session Participant may set the value of the Session Restart Flag of their Signon Group to indicate a restart session. Otherwise the Session Restart Flag will indicate an original session. See Section 6.1.12.

o If the Session Restart Flag of the Session Controller indicates an original session and that of the Session Responder indicates a restart session, the Session Controller will transmit a PTERM so that the aborted session may be concluded.

The following rules apply to the Message Transmitter for an aborted Message Transfer Phase.

o The Message Transmitter for an aborted Message Transfer Phase must retransmit any messages or control groups for which they have not received an expected response. An Emergency Signoff Group is not an expected response but an NMACK is an expected response to a message.

o A Message Transmitter in an aborted Message Transfer Phase, may not retransmit messages from message streams prior to the one during which the session was aborted. That is, messages from a prior (already acknowledged) message stream may not be retransmitted.

o If the Message Transmitter guaranteed duplicate message re-transmission for the aborted session, the Transmission Status Flag data element of the Message Header of each re-transmitted message must specify a duplicate message.

o If the Message Transmitter did not guarantee duplicate message re-transmission for the aborted session, the Transmission Status Flag for the first re-transmitted message must specify a replacement message.

The following rules apply to the Message Receiver for a normal Message Transfer Phase:

o If the Message Transmitter has guaranteed duplicate message re-transmission for the session, no message suspension is required.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 43 o If the Message Transmitter has not guaranteed duplicate message re-transmission for the session, the Message Receiver must suspend processing of received messages until, after transmitting one or more groups, they receive a valid group other than an Emergency Signoff Group.

o If a communications session is aborted, then all messages in suspense at the time of the abort remain in suspense.

The following rules apply to a Message Receiver for a restarted Message Transfer Phase if the Message Transmitter did not guarantee duplicate message re - transmission.

o If the first group (following the Signon Phase) received by the Message Receiver is a control group that they would next expect to receive, had the Message Transfer Phase not aborted, (i.e. Message Header, STERM or PTERM) they continue processing as if the MTP had not failed.

o If the first group received is not a next expected control group, it must be a Message Header. The Message Sequence Number data element of the Message Header must be that of a suspended message and the Transmission Status Flag must specify a replacement message. In this case, the Message Receiver releases from suspense (for processing) those messages with Message Sequence Number prior to that of the newly received message and purges the remaining suspended messages. The newly received message is then suspended and the Message Receiver continues processing from this point as if the MTP had not failed.

o If the first group or the first message received is in error (a message which is "NMACKed" is not an error for restart purposes), the Message Receiver will purge all data received in the restarted MTP and initiate an Emergency Signoff at the first opportunity.

5.7.3 Option A: Additional Requirement

If the Message Acknowledgement Option A is in effect for a communications session, both participants must specify duplicate message re-transmission for the session.

6.0 GROUPS (DETAIL)

6.1 Documentation Format

Each of the control groups are documented in three sub-sections which cover Group Format, Group Data Elements and an example of a hypothetical group.

The Group Format sub-section provides an overall picture of the control group including its header and each data element of the group in its proper sequence. This sub-section also provides the specified value for the data elements which make up the group header itself. Where specified, the value for these data elements must be followed exactly. For the data elements which make up the group, following the header, this sub-section also provides each element's length attribute in characters, its data type and its presence code. (See Standard No.C900 for a full explanation of data element attributes).

The sub-section covering the group data elements provides a detailed description of the function and content of each data element which is found in the group outside of the header.

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 44 The last sub-section for each group is a hypothetical example of a completely filled-out control group including header and data elements. This example is provided solely for clarification and is not intended to, in any way, suggest an optimum selection of the various codes or options which may be available for any data elements within the control groups.

Note that these following sections provide the detail of the various control groups. A general description of these control groups, their purpose and relationship to each other is found in prior sections of this document and should be considered prerequisite reading for these detailed following sections.

Signon Group Format

Sequence Refer. Start Data Presence Number Name Data Element Pos Length Class Type Code

-- Group Header (see below) 1 10 --

SOG01 MCADD Machine Address (Origination) 11 12 AN M SOG02 PSSWD Password (Session) 23 12 AN M SOG03 SRNFO Session Reference Number 35 4 N M SOG04 CPUCD Capacity Unit Code 39 1 CD N M SOG05 CAP Capacity 40 8 N M SOG06 CDPCD Communications Device Protocol Code 48 4 IC AN M SOG07 SYSCD System Type Code 52 6 IC AN M SOG08 CSRLV Interface Software Revision Level 58 4 N SOG09 MTRLV Message Standard Revision Level 62 2 N M SOG10 MACKO Message Acknowledgement Option 64 4 N M SOG11 RCVCT Receive Options Count 68 2 N M SOG12 SRSTF Session Restart Flag 70 1 CD N M SOG13 SGRCD Signon Response Code 71 4 CD T SOG14 ERRCD Error Code 75 6 CD AN SOG15 RCVTP Recovery Type Flag 81 1 CD N M SOG16 MTPHL Message Transfer Phase Limit 82 2 CD N M SOG17 TRMCU Terminator Count Unit Code 84 1 CD N SOG18 CTVCD Count Verification Indicator 85 1 CD N

Reserved for Future Use 86 40

TOTAL DATA LENGTH 115

SIGNON GROUP HEADER VALUES

H1 Group Designator Value 4SOG H2 Total Group Length 125 H3 Format Flag b H4 Reserved for Future Use (blanks) bb

1.1 Machine Address (Origination) (SOG01)

- Network Prefix Portion - Area Code Portion - Originator Code Portion

(As discussed in section 5.0, a two-way signon procedure is specified for broker-company data communications. This signon is at a machine-to-machine level.)

The Machine Address (Origination) data element, therefore, is a unique identifier for the data processing device originating this portion of the two-way signon process. It is a 12-character field in which the first three characters are a Network Prefix. In a direct link, this portion of the data element should be ignored. The next three characters are the numeric telephone area code in which the device is located and the last 6 characters are a self-assigned code for the organization using the device.

The 12-character Machine Address will be the first 12 characters of a more complex Message Address described in the Message Header group.

1.2 Password (Session) (SOG02)

The Password (Session) data element is used to provide unique identification to prevent accidental or unauthorized exchanges of information. Passwords will be self-assigned by users and will not be published generally. Passwords should be communicated on an "ad hoc" basis between users who wish to communicate with each other. They are subject to change at the discretion of individual communicating pairs as required to maintain an appropriate level of security. It is the responsibility of each user to maintain a list of their own passwords as well as the current passwords of those parties with whom they will authorize communications.

1.3 Session Reference Number (SOG03)

The Session Reference Number is a numeric data element that is incremented by the sender before the start of any session with any party. Each party generates its own number. It is not a control number. In the event of an aborted and/or re-started session, the Session Reference Number will be incremented.

1.4 Capacity Unit Code (SOG04)

The Capacity Unit Code is an indicator as to the units used in expressing the capacity of the system transmitting this Signon Group to accept data during this session. The codes are: »Capacity Unit Code (CPUCD) Code Description

0 Capacity is expressed in characters 1 Capacity is expressed in element groups (maximum group length is 240 characters) «

1.5 Capacity (SOG05)

The Capacity data element establishes the maximum capacity of the system transmitting this Signon Group to receive data during this session. (This provision is made to meet known constraints which

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 47 exist in the capability of some current brokerage systems.) It is the responsibility of the responding party to assure that the sum of the Group Length data elements of all the groups they transmit does not exceed this limit. If the responding party has more data than can be handled by the receiving system, either smaller messages must be constructed, the transmission must be postponed, or manual intervention must occur. The Capacity data element is coded:

All Zeros = No messages are to be sent in the return transmission All Nines = Unlimited receive capacity Other Values = The specific capacity

Note that capacity, as specified in the Sign-on group, (SOG) is meant to reflect actual system capacity to receive and store messages (including headers, trailers, transaction groups, etc.). Control groups (such as Sign-on, Sign-off, MACK, NMACK, STERM, etc., should not be figured in capacity, since actual extended storage of these groups should not be necessary. All systems should anticipate a minimum storage capacity to complete a normal exchange of control groups in a session. Hence, that minimum capacity should not be reflected in the capacity specified at Sign-on.

1.6 Communications Device Protocol Code (SOG06)

This code expresses the communications environment under which this session is to proceed when a port is called which can support multiple device types which use a variation of a common data link protocol. The codes will be specified by each sender/receiver pair.

Note: The communications Device Protocol Code is passed only within the Signon Group. It is a single session-oriented code that is sufficient for handling any combination of data compression/decompression techniques which may be used during a single "physical" session. If a Value-Added Network is being used as an intermediary, however, and the "physical" sessions which the Network will conduct between sender and ultimate receiver utilizes different protocols, data compression techniques, etc., it is the responsibility of the Network to "logically" decompress the data from the first session and recompress it (possibly using different techniques) for the second session. This does not imply that under these circumstances, data must be stored in decompressed form within the Network, only that a "logical" decompression and recompression must occur. For CSIO compression, the following code values will be used (refer to CSIO Syntax Rules for compression algorithm):

Code Specification

X25U X25 Uncompressed X25C X25 Compressed

COMMENTARY

It is anticipated that in implementing this Standard within the context of a value added network, the supplier of the network service will have to reconstruct this data element when receiving messages from a single origin, to be delivered to multiple destinations. The nature of the reconstruction will depend upon what level of service the receiver has requested from the network. It will range from no change (and therefore, no reconstruction) for those receivers who wish messages passed to them in the same format as received by the vendor, to changing.

This field is provided for possible use in a future implementation. In the Intelligent Access implementation, the default compression technique will be 3780.

Data element SOG06 will always specify the data link protocol that the current message stream appears in. The network supplier will presumably access some table of value added functions, organized by user, to determine what network processing, if any needs to be performed on this data element.

1.7 System Type Code (SOG07)

This code will be assigned by individual users to specifically describe the originating system being used for the communications session. Examples might be ARC001, CICS15, or any other code which meaningfully describes the total system configuration of the originator.

1.8 Interface Software Revision Level (SOG08)

This data element allows the sender to notify the receiver as to the software used to construct messages. This enables the coordination necessary to assure that the Messages being sent can be accurately received. Any relationship of that data element upward to the Transaction level is coincidental.

1.9 Message Standard Revision Level (SOG09)

This element reflects the individual's specific revision level of the Batch Transmission Session and Message Structure Standard under which communication is proceeding. For example, using Standard Number C110-2.0, the Standard revision level will have a value of 20.

1.10 Message Acknowledgement Option (SOG10)

The Message Acknowledgement Option data element is used to confirm the type of message acknowledgement agreed to by the session participants. The specific codes are:

0000 = No message acknowledgements or STERMS will be sent. (Option A)

0001-8999 = Message acknowledgements will be sent following whatever number of messages is specified. For example, if the code is 0001, an acknowledgement will be sent in response to each individual message before the next message is sent. (Option C)

9998 = All message acknowledgements will be sent following receipt of the Stream Terminator Group. If there were, for instance, 7 messages in the stream, 7 MACKS would be sent by the receiver following receipt of the Stream Terminator Group (Option C)

9999 = A single stream acknowledgement (a special case of the Stream Terminator Group) will be sent following receipt of the Stream Terminator Group (Option B)

1.11 Receive Options Count (SOG11)

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 49 This indicator identifies the number of Receive Options Control Groups which follow the Signon Group in this transmission stream. Its values are:

00 = No Receive Options Groups are being sent and the responder in this session has blanket authority to transmit messages from any authorized recipient to any authorized originator up to the capacity indicated by data element SOG05 in this Signon Group. Note: An agency/brokerage system is not required to respond to an option other than 00.

99 = No Receive Options Control Groups are being sent. Traffic can be delivered up to the capacity indicated by data element SOG05 in this Signon Group but only for those users from whom messages will be sent in this session. (See Section 5.4).

01-98 = 1 to 98 Receive Options Control Groups follows.

1.12 Session Restart Flag (SOG12)

This is a flag sent by the Session Participant if they are re-starting an aborted session. Its purpose is to assure that the parties are in sync at the signon time or, if not, that they are aware of that fact. It informs the receiver that additional checking might be necessary to validate messages in this session since a possibility exists that they may already have been received. The codes are: »Session Restart Flag (SRSTF)

Code Description

0 Original session 1 This is a restart session «

1.13 Signon Response Code (SOG13)

The Signon Response Code will have a value of all blanks in the Signon Group. It is a data element which is used in the Signon Rejection Group (where it is described) and is contained in the Signon Group in order to provide a single group format for both the Signon and Signon Rejection Groups.

1.14 Error Code (SOG14)

The Error Code is also used in the Signon Rejection Group and has a value of blanks in the Signon Group.

1.15 Recovery Type Flag (SOG15)

This code specifies whether messages which will be re-transmitted because of an abort of the current session will be duplicates or replacements of the original messages. A message is a retransmitted message if it has the same Message Sequence Number as a previously delivered message (allowing for Message Sequence Number Rollover). A message is a duplicate message of a previously delivered message if the transactions contained in the two messages are character by character equal, otherwise it is a replacement. The values of the Recovery Type Flag are: »Recovery Type Flag (RCVTP)

0 Duplicate message re-transmissions are not guaranteed. and re-transmitted messages will be replacements 1 Duplicate message retransmission is guaranteed «

1.16 Message Transfer Phase Limit (SOG16)

This data element is used to limit the number of pairs of Message Transfer Phases for the session. The session controller will set its value. However, if the session responder cannot deal with more than one phase pair, they may override a value of 00 and replace it with 01. If so, the session controller must accept the override.

A restarted session need not have the same n count as the original session. The values of the data element are: »Message Transfer Phase Limit (MTPHL)

Code Description

00 There is no limit on the number of Message Transfer Phases 01 There may be only one pair of Message Transfer Phases in the session «

COMMENTARY

This facility is provided to accommodate some existing system's inability to accept more than one Message Transfer Phase in a session.

1.17 Terminator Count Unit Code (SOG17)

This data element specifies the units of measurement for the value of the Total Data in Phase data element of the Stream Terminator Group. It is present in the Signon Group to permit the "physical" Message Receiver to count correct units. The codes are: »Terminator Count Unit Code (TRMCU)

Code Description

0 Value is in characters 1 Value is in element groups «

1.18 Count Verification Indicator (SOG18)

This data element is used to specify that the Count Verification Feature of Message Acknowledgement Option B is in effect. It is coded as follows: »Count Verification Indicator (CTVCD)

Code Description

C110 – 12(i) ©2012 CSIO TRANSMISSION SESSION STANDARD OPTIONS page 51 0 Option is not in effect 1 Both Total Data and Messages in Phase data elements will be transmitted for verification 2 Only Total Data in Phase will be transmitted for verification 3 Only Total Messages in Phase will be transmitted for verification «

1.19 Reserved for Future Use

This data element must be blank.

BYTE 1 Header Group Designator 4SOG Group Length 125 Format Flag b Reserved for Future Use bb Data Elements Machine Address (Origination) bbb914AGENT1 Password (Session) INSAGENTbbbb Session Reference Number 0123 Capacity Unit Code 0 Capacity 01000000 Communication Device Protocol Code bbbb System Type Code ARC02b Interface Software Revision Level 0000 Message Standard Revision Level 20 Message Acknowledgement Option 0000 Receive Options Indicator 00 Session Restart Flag 0 Signon Response Code bbbb Error Code bbbbbb Recovery Type Flag 0 Message Transfer Phase Limit 00 Terminator Count Unit Code 0 Count Verification Indicator 0 Reserved for Future Use (40 blanks)

BYTE 125

Signon Rejection Group Format

SOR01 MCADD Machine Address (Origination) 11 12 AN M SOR02 PSSWD Password (Session) 23 12 AN SOR03 SRNFO Session Reference Number 35 4 N SOR04 CPUCD Capacity Unit Code 39 1 CD N SOR05 CAP Capacity 40 8 N SOR06 CDPCD Communications Device Protocol Code 48 4 IC AN SOR07 SYSCD System Type Code 52 6 IC AN SOR08 CSRLV Interface Software Revision Level 58 4 N SOR09 MTRLV Message Standard Revision Level 62 2 N SOR10 MACKO Message Acknowledgement Option 64 4 N SOR11 RCVCT Receive Options Indicator 68 2 N SOR12 SRSTF Session Restart Flag 70 1 CD N SOR13 SGRCD Signon Response Code 71 4 CD AN M SOR14 ERRCD Error Code 75 6 CD AN M SOR15 RCVTP Recovery Type Flag 81 1 CD N SOR16 MTPHL Message Transfer Phase Limit 82 2 CD N SOR17 TRMCU Terminator Count Unit Code 84 1 CD N SOR18 CTVCD Count Verification Indicator 85 1 CD N

SIGNON REJECTION GROUP HEADER VALUES

H1 Group Designator Value 4SOR H2 Total Group Length 125 H3 Format Flag b H4 Reserved for Future Use (blanks) bb

The description of data elements SOR01 through SOR12 and SOR15 through SOR18 is identical to that found in the Signon Group for the corresponding data elements. These data elements are returned exactly as received.

1.1 Machine Address (Origination) (SOR01)

Refer to definition of 4SOG01. This data element is returned exactly as received.

1.2 Password (Session) (SOR02)

1.3 Session Reference Number (SOR03)

1.4 Capacity Unit Code (SOR04)

1.5 Capacity (SOR05)

1.6 Communications Device Protocol Code (SOR06)

1.7 System Type Code (SOR07)

1.8 Interface Software Revision Level (SOR08)

1.9 Message Standard Revision Level (SOR09)

1.10 Message Acknowledgement Option (SOR10)

1.11 Receive Options Count (SOR11)

1.13 Signon Response Code (SOR13)

The Signon Response Code is used to identify the data element which is in error in the Signon transaction. The codes are: »Signon Response Code (SGRCD)

Code Description

SHnn The error is in Signon Group header element Hnn. SDnn The error is in Signon Group data element SOGnn. mmHn The error is in header element Hn of Receive Options Control Group number mm. The Receive Options Control Groups are numbered in the order of transmission beginning with the number 1. mmnn The error is in data element ROCnn of Receive Options Control Group number mm. «

1.14 Error Code (SOR14)

The error code indicates the nature of the error condition found. The codes are: »Error Code (ERRCD)

Code Description

SOG000 Specified field error. A specified field does not contain its specific value. SOG001 Data type error. The data type for the element is incorrect. For instance, numeric information appears in an alphabetic field. SOG002 Edit error. The data content of the field in question does not meet the specified editing criteria. «

1.15 Recovery Type Flag (SOR15)

1.16 Message Transfer Phase Limit (SOR16)

1.17 Terminator Count Unit Code (SOR17)

1.18 Count Verification Indicator (SOR18)

BYTE 1 Header Group Designator 4SOR Group Length 125 Format Flag b Reserved for Future Use bb Data Elements Machine Address (Origination) bbb914AGENT1 Password (Session) INSAGENTbbbb Session Reference Number 0123 Capacity Unit Code 0 Capacity 01000000 Communication Device Protocol Code bbbb System Type Code ARC02b Interface Software Revision Level 0000 Message Standard Revision Level 20 Message Acknowledgement Option 0000 Receive Options Indicator 00 Session Restart Flag 0 Signon Response Code SD02 Error Code SOG001 Recovery Type Flag 0 Message Transfer Phase Limit 00 Terminator Count Unit Code 0 Count Verification Indicator 0 Reserved for Future Use (40 blanks)

BYTE 125

Receive Options Control Group Format

ROC01 SBADD Subaddress (Destination) 11 6 AN ROC02 MSADD Message Address (Origination) 17 18 AN ROC03 CAPUN Capacity Unit Code 35 1 CD N M ROC04 CAP Capacity 36 8 N M ROC05 PROPT Processing Option 44 20 AN ROC06 ROCRV Reserved for Future Use 64 4 T ROC07 SBADD Subaddress (Destination) 68 6 AN ROC08 MSADD Message Address (Origination) 74 18 AN ROC09 CAPUN Capacity Unit Code 92 1 CD N M ROC10 CAP Capacity 93 8 N M ROC11 PROPT Processing Option 101 20 AN ROC12 ROCRV Reserved for Future Use 121 4 T ROC13 SBADD Subaddress (Destination) 125 6 AN ROC14 MSADD Message Address (Origination) 131 18 AN ROC15 CAPUN Capacity Unit Code 149 1 CD N M ROC16 CAP Capacity 150 8 N M ROC17 PROPT Processing Option 158 20 AN ROC18 ROCRV Reserved for Future Use 178 4 T ROC19 SBADD Subaddress (Destination) 182 6 AN ROC20 MSADD Message Address (Origination) 188 18 AN ROC21 CAPUN Capacity Unit Code 206 1 CD N M ROC22 CAP Capacity 207 8 N M ROC23 PROPT Processing Option 215 20 AN ROC24 ROCRV Reserved for Future Use 235 4 T

RECEIVE OPTIONS CONTROL GROUP HEADER VALUES

H1 Group Designator Value 4ROC H2 Total Group Length 238 H3 Format Flag b H4 Reserved for Future Use (blanks) bb

ROC01 through ROC06 is a set of related data elements which, taken together, specify the delivery of a set of messages and the maximum amount of data that may be delivered for that set.

1.1 Subaddress (Destination) (ROC01)

The Subaddress data element identifies the shared user or second-level processor for which messages are to be delivered in this session.

1.2 Message Address (Origination) (ROC02)

The Message Address data element is used by the receiver to qualify and select the messages to be received. Only messages sent from this Message Address are to be considered eligible for delivery subject to any capacity limitations. If Subaddress is specified, these two data elements are operated in conjunction to specify the total message delivery option. The format of this data element is the same as the format of the Origination Message Address data element of the Message Header Group (MHG01).

1.3 Capacity Unit Code (ROC03)

The Capacity Unit Code indicates the units in expressing the Capacity data element which follows. The codes are: »Capacity Unit Code (CAPUN)

Code Description

0 Capacity expressed in characters 1 Capacity expressed in element groups (maximum group size is 240 characters) «

1.4 Capacity (ROC04)

The Capacity data element establishes the maximum capacity of the transmitting system to receive data in the return transmission. It is the responsibility of the responding party to assure that this limit is not exceeded. The Capacity data element is coded:

All zeros = No messages are to be sent to/from this Subaddress/Message Address pair

All nines = Unlimited capacity of receive

Other = Exact capacity is specified

As in the Sign-on group (SOG05), capacity as specified on the Receive Options Group (ROC04) should reflect actual system capacity to receive and store messages (including headers, trailers, and transaction groups). Control groups (such as Sign-on, Sign-off, MACK, NMACK, STERM, etc., should not be figured in capacity since actual extended storage of these groups should not be necessary.

This data element is intended to be used when communicating via a value-added network and the contents will be specified at a future time. This, as well as other network-oriented data elements is included in order to avoid the necessity of redesigning the various control groups when a value-added network is used.

1.6 Reserved for Future Use (ROC06)

This data element must be blank.

BYTE 1 Header Group Designator 4ROC Group Length 238 Format Flag b Reserved For Future Use bb Data Elements Subaddress (Destination) AGENT1 Message Address (Origination) (18 blanks) Capacity Unit Code 0 Capacity 01000000 Processing Options (20 blanks) Reserved for Future Use bbbb Subaddress (Destination) AGENT2 Message Address (Origination) (18 blanks) Capacity Unit Code 1 Capacity 00000500 Processing Options (20 blanks) Reserved for Future Use bbbb --- (114 blanks)

BYTE 238

Signoff Group Format

SOF01 SNOFT Signoff Type 11 1 CD N M SOF02 SNOFC Signoff Condition 12 2 CD N SOF03 SOFRV Reserved for Future Use 14 40 T SOF04 SNOFI Signoff Information Field 54 187 T

SIGNOFF GROUP HEADER VALUES

H1 Group Designator Value 4SOF H2 Total Group Length 240 H3 Format Flag b H4 Reserved for Future Use bb

1.1 Signoff Type (SOF01)

The Signoff Type data element is used by the Signoff Initiator to specify either a normal signoff or an emergency signoff. The Signoff Type is coded as follows: »Signoff Type (SNOFT)

Code Description

0 Normal Sign off 1 Emergency Sign off «

1.2 Signoff Condition (SOF02)

The Signoff Condition data element is used by the initiator of an Emergency Signoff to specify the condition which resulted in the signoff initiation. It is coded as follows: (See Section 5.4) »Signoff Condition (SNOFC)

Code Description

00 Unspecified condition in Signoff Initiator's system 01 Unspecified condition related to data received 02 Communications application program receive time out 03 Loss of group synchronization (e.g.: Presence of an alpha or special character in a group length field) 04 Unexpected group received (e.g.: Presence of a valid control group received in an incorrect order - receipt of a second message header before receiving a message trailer, etc.) 10 Count Verification Failure 11 Invalid Message Sequence Number 12 Invalid Message Acknowledgement Group «

1.3 Reserved for Future Use (SOF03)

This data element must contain a value of 40 blanks.

1.4 Signoff Information Field (SOF04)

This data element may be used in an emergency signoff to transmit a message regarding the nature of the emergency. For example, it may be used to transmit the message header of the message which brought about the signoff.

Header BYTE 1 Group Designator 4SOF Group Length 240 Group Flag b Reserved for Future Use bb Data Elements Signoff Type 0 Signoff Condition 00 Reserved for Future Use (40 blanks) Signoff Information Field (187 blanks)

BYTE 240

Message Acknowledgement Group Format

MAK01 MSADD Message Address (Origination) 11 18 AN MAK02 MSADD Message Address (Destination) 29 18 AN MAK03 MSQNO Message Sequence Number 47 6 N MAK04 MRFNO Network Reference Number 53 20 AN

MESSAGE ACKNOWLEDGEMENT GROUP HEADER VALUES

H1 Group Designator Value 4MAK H2 Total Group Length 072 H3 Format Flag (blank) b H4 Reserved for Future Use (blanks) bb

1.1 Message Address (Origination) (MAK01)

Refer to definition of 1MHG01. This data element along with all other data elements in this group are returned exactly as received.

1.2 Message Address (Destination) (MAK02)

1.3 Message Sequence Number (MAK03)

1.4 Network Reference Number (MAK04)

BYTE 1 Header Group Designator 4MAK Group Length 072 Format Flag b Reserved For Future Use bb Data Elements Message Address (Origination) bbb914AGENTIOFFOO1 Message Address (Destination) bbb121COMPYIB00123 Message Sequence Number 001234 Network Reference Number (20 blanks)

BYTE 72

Negative Message Acknowledgement Group Format

NMK01 MSADD Message Address (Origination) 11 18 AN NMK02 MSADD Message Address (Destination) 29 18 AN NMK03 CNTNO Contract Number 47 10 AN NMK04 PSSWD Password (User) 57 12 AN NMK05 SYSCD System Type Code 69 6 IC AN NMK06 MSRVL Message Software Revision Level 75 4 N NMK07 MSQNO Message Sequence Number 79 6 N NMK08 MTDTM Message Transmission Date/Time 85 13 N NMK09 CNTUN Count Unit Code 98 1 CD N NMK10 SPCHD Special Handling 99 10 AN NMK11 MTRLV Message Standard Revision Level 109 2 N NMK12 TRXSF Transmission Status Flag 111 1 CD N NMK13 MSGRC Message Response Code 112 4 AN NMK14 ERRCD Error Code 116 6 CD AN NMK15 NRFHO Network Reference Number 122 20 AN NMK16 NRSVD Network Reserved for Future Use 142 20 T

MESSAGE ACKNOWLEDGEMENT GROUP HEADER VALUES

H1 Group Designator Value 4NMK H2 Total Group Length 161 H3 Format Flag b H4 Reserved for Future Use (blanks) bb

All data elements with the exception of NMK13, Message Response Code and NMK14, Error Code are identical to the corresponding data elements in the Message Header Group. These data elements are returned in the Negative Message Acknowledgement Group exactly as received.

1.1 Message Address (Origination) (NMK01)

Refer to definition of 1MHG01. This data element is returned exactly as received.

1.2 Message Address (Destination) (NMK02)

1.3 Contract Number (NMK03)

1.4 Password (User) (NMK04)

1.5 System Type Code (NMK05)

1.6 Message Software Revision Level (NMK06)

1.7 Message Sequence Number (NMK07)

1.8 Message Transmission Date/Time (NMK08)

1.9 Count Unit Code (NMK09)

1.10 Special Handling (NMK10)

Refer to definition of 1MHG10.Data element is returned exactly as received.

1.11 Message Standard Revision Level (NMK11)

1.13 Message Response Code (NMK13)

The Message Response Code is used to identify the element which is in error in the Message Header Group or Message Trailer Group. The data elements which will be edited are as specified in Section 5.5.2.2 (Option B description). The data element codes are as follows.

MHnn = The error is in Message Header Group header element Hnn. MDnn = The error is in Message Header Group data element MHGnn. (Initially, only the Machine Address and Message Sequence data elements are to be checked.) THnn = The error is in Message Trailer Group header element Hnn. TDnn = The error is in Message Trailer Group data element MTGnn. (Initially, only the Counts are to be checked.) ZZ99 = Invalid Message Sequence Number. These codes are not valid for use unless the physical and logical communication pairs are one and the same. ZZnn = The error is in an element not contained within the message header or trailer. An nn value of 00 would indicate a totally undefined error. These codes are not valid for use unless the physical and logical communication pairs are one and the same.

1.14 Error Code (NMK14)

The error code indicates the nature of the error condition found. The codes are as follows: »Error Code (ERRCD)

Code Description

NMK000 Specified field error. A specified field does not contain its specified value. NMK001 Data type error. The data type for the element is incorrect. For instance, numeric information appears in an alphabetic field. NMK002 Edit error. The data content of the field in question does not meet the specific editing criteria. NMK003 Unspecified error. «

1.15 Network Reference Number (NMK15)

1.16 Network Reserved for future use (NMK16)

BYTE 1 Header Group Designator 4MAK Group Length 161 Group Flag b Reserved For Future Use bb Data Elements Message Address (Origination) bbb914AGENTlOFFOO1 Message Address (Destination) bbb121COMPYlB00123 Contract Number bbbbbbbbbb Password (Message) INSAGENTbbbb System Type Code RED03b Message Software Revision Level 0002 Message Sequence Number 001412 Message Transmission Date/Time 8111061903412 Count Unit Code 0 Special Handling bbbbbbbbbb Message Standard Revision Level 01 Transmission Status Flag 0 Message Response Code MD03 Error Code NMKOO1 Network Reference Number (20 blanks) Network Reserved for Future Use (20 blanks)

BYTE 161

Stream Terminator Group Format

STG01 TOTDF Total Data in Phase 11 8 N STG02 TOTMG Total Messages 19 4 N STG03 ADDDF Additional Data Flag 23 1 CD N M STG04 STRTR Stream Terminator Response Code 24 4 AN STG05 ERRCD Error Code 28 6 CD AN

STREAM TERMINATOR HEADER VALUES

H1 Group Designator Value 4STG H2 Total Group Length 043 H3 Format Flag (blank) b H4 Reserved for Future Use bb

1.1 Total Data in Phase (STG01)

The Total Data in Phase data element specifies the total data transmitted in the Message Transfer Phase up to and including the Stream Terminator Group containing this data element. The unit of measurement is either element groups or characters and is specified by the Terminator Count Unit Code of the Signon Group. If the unit of measurement is characters, the value of the Total Data in Phase data element is equal to the sum of the values of the Group length data elements for each element group transmitted in the Message Transfer Phase.

1.2 Total Messages (STG02)

The total number of messages or message acknowledgements, as appropriate, transmitted in the Message Transfer Phase.

1.3 Additional Data Flag (STG03)

The Additional Data Flag is used to notify the receiver whether or not all messages were sent or if additional messages remain to be sent but the capacity limit has been reached. The specific codes are:

0 = Complete 1 = Incomplete (More to Come)

The additional data may either be for same message address or for entities other than ones who have received messages in this transmission stream.

1.4 Stream Terminator Response Code (STG04)

The Stream Terminator Response Code may be used by the receiver to notify the sender, in the event of an error condition, that the count fields sent by the sender in their Stream Terminator did not agree with the corresponding accumulated counts. The contents of the data element will identify which count is in disagreement. The specific codes are:

bbbb = No Error 0001 = Total Data in Phase Error 0002 = Total Messages Error

This data element is operative only if message acknowledgement opt.B is in effect and the Count Verification Feature of that option is also in effect.

1.5 Error Code (STG05)

The error codes indicate the nature of the error condition found: »Error Code (ERRCD) Code Description

STG000 Indicated field error. The indicated field does not contain a proper value. «

BYTE 1 Header Group Designator 4STG Group Length 043 Group Flag b Reserved for Future Use bb Data Elements Total Data in Phase 00021690 Total Messages 0003 Additional Data Flag 0 Stream Terminator Response Code bbbb Error Code bbbbbb Reserved for Future Use (10 blanks)

BYTE 43

Phase Terminator Group Format

PHASE TERMINATOR HEADER VALUES

H1 Group Designator Value 4PTG H2 Total Group Length 050 H3 Format Flag (blank) b H4 Reserved for Future Use bb

1.1 Reserved for Future Use

This data element is reserved space for future use and must be blank filled.

BYTE 1 Header Group Designator 4PTG Group Length 050 Group Flag b Reserved for Future Use bb Data Elements Reserved for Future Use (40 blanks)

BYTE 50

Control Request Group Format

CRG01 MCADD Machine Address (Origination) 11 12 AN M CRG02 PSSWD Password (Session) 23 12 AN M CRG03 ERCD Error Code 25 2 CD N

CONTROL REQUEST GROUP HEADER VALUES

H1 Group Designator Value 4CRG H2 Total Group Length 076 H3 Format Flag b H4 Reserved for Future Use bb

1.1 Machine Address (Origination) (CRG01)

Refer to definition of 4SOG01. The content of this data element is identical to the content of the user's 4SOG01. (See section 6.2.2).

1.2 Password (Session) (CRG02)

Refer to definition of 4SOG02. The content of this data element is identical to the content of the 4SOG02.

1.3 Error Code (CRG03)

The Error Code will have a value of blank in the Control Request Group. It is a data element which is used in the Control Request Rejection Group and is contained in the Control Request Group in order to provide a single format for the two groups.

BYTE 1 Header Group Designator 4CRG Group Length 076 Group Flag b Reserved for Future Use bb Data Elements Machine Address (Origination) bbb914AGENT1 Password (Session) INSAGENTbbb Error Code bb Reserved for Future Use (40 blanks)

BYTE 76

Control Request Rejection Group Format

CRR01 MCADD Machine Address (Origination) 11 12 AN M CRR02 PSSWD Password (Session) 23 12 AN M CRR03 ERCD Error Code 25 2 CD N M Reserved for Future Use 27 40

CONTROL REQUEST GROUP HEADER VALUES

H1 Group Designator Value 4CRR H2 Total Group Length 076 H3 Format Flag b H4 Reserved for Future Use bb

1.1 Machine Address (Origination) (CRR01)

This data element is used to return the value of the data element CRG01 of the Control Request Group exactly as received.

1.2 Password (Session) (CRR02)

This data element is used to return the value of the data element CRG02 of the Control Request Group exactly as received.

1.3 Error Code (CRR03)

The Error Code indicates the reason for transmission of the Control Request Rejection Group. The codes are: »Error Code (ERCD)

Code Description

01 Invalid Group Designator in the received Control Request Group 02 Invalid value of CRG001 03 Invalid value of CRG002 10 Session Answerer will not accept control of the session «

BYTE 1 Header Group Designator 4CRG Group Length 076 Group Flag b Reserved for Future Use bb Data Elements Machine Address (Origination) bbb914AGENT1 Password (Session) INSAGENTbbb Error Code 01 Reserved for Future Use (40 blanks)

BYTE 76

Date Page &/or Release Issued Description Section

2000 Jan/2000 Released

2006 June/2006 Amended definition of 3.2 “Mail Box Delivery Notification Message” (MR06-396)

2012 Mar/2012 Add the ability to send XML transactions through CSIOnet (MR2012- 010)

In 1997 the majority of broker interface transactions were transmitted via ICEnet which was at that time the Insurance industries value added network. This became very costly as more and more brokers were implementing broker interface and the data volumes increased dramatically.

In 1996 a CSIO project was launched to investigate more cost effective ways of transmitting policy information. It was found that the utilization of Internet technologies would reduce the telecommunications cost to the industry by approximately 90%.

CSIO lead a project to build a secure telecommunication environment and in 1998 and 1999 the industry migrated from ICEnet to an industry intranet. This resulted in a change to the way that CSIO transactions are transmitted.

2.0 TRANSACTION FLOW

In order to insure that messages get from one place to another successfully a standard transaction flow was established. The following steps take place:

1. The sender connects to the IP (Internet Protocol) network. 2. The sender sends a message to the receiver’s POP3(Post Office Protocol) mailbox. 3. The POP server replies to the sender notifying them that the receivers mail box has successfully received the message. 4. The receiver connects to the network. 5. The receiver retrieves the message from their mailbox. 6. The receiver sends an acknowledgement back to the sender informing them that the message has been received successfully. This acknowledgement does not mean that the transaction is valid or approved but that the receiver has received a message that conforms to the CSIO transmission standard.

3.0 CSIO STANDARD TRANSMISSION MESSAGES

The CSIO standard for Internet transmission utilises 3 SMTP (Simple Mail Transfer Protocol) transmissions.

3.1 CSIO Data Transmission

The CSIO data transmission is the transmission that contains the insurance business data in CSIO standard format. Ie. The 1MHG and its contents. The business data is a base64 MIME encoded attachment to an SMTP mail message. The SMTP message has a standard format. As a security precaution, if the message does not conform to the exact CSIO standard format, the message is disregarded by the receiving system.

The following is the standard for CSIO compliant SMTP messages:

The destination userid. i.e. Who you are sending the message to

3.1.2 “From:”

The sender’s userid. i.e. your userid

3.1.3 “Subject:”

This is the index information in both the audit trail and archive. Each data element is separated by a period. The line must be in the following format:  "Subject: EDI Xmit Msg-Id#:" This is a fixed text field for AL3 transaction Or "Subject: XML Xmit Msg-Id#:" This is a fixed text field for XML transactions.  “{date stamp}.” The date stamp generated in the following way. DATE(YYYYMMDD) +ticks since midnight. There are 18.2 ticks per second. This corresponds to the C function biostime().  “{a userid}.” The userid is the senders userid.

3.1.4 “Return-Receipt-To:”

The userid that will receive delivery notifications, usually the same as “From” above.

3.1.5 “Content-Type:”

Must specify at least "BOUNDARY="{unique piece of text}". This text delineates the start and end of the message.

3.1.6 “Content-Type:” (in body)

Must specify at least name="filename.xxx"

3.1.7 “Content-Disposition:”

Must specify at least filename="filename.xxx"

3.1.8 MIME Encoded Business Message

Use Base64 mime encoding for the business message. Surround MIME (Multi Purpose Internet Extensions) and mime header with the boundary separator. See the example below:

Note #1: It is allowable to specify the transaction in the second MIME boundary providing that the first MIME boundary contains no mime headers or data. This accommodates the use of some UNIX style MIME generation software.

Note #2: The body of this document does not contain any text, just MIME encoding.

Return-Path: Received: from 10.254.254.28 ([10.254.254.28]) by csio (JAMES SMTP Server 2.3.1) with SMTP ID 778 for ; Wed, 15 Feb 2012 15:02:54 -0700 (MST) To: From: Another Co. Subject: EDI Xmit Msg-Id#:[email protected] OR Subject: XML Xmit Msg-Id#:[email protected] MIME-Version: 1.0 Return-Receipt-To: ABC Message-Id: <[email protected]> Content-Type: MULTIPART/MIXED; BOUNDARY="=====_34934934312BDY_===" --=====_34934934312BDY_=== Content-Type: application/octet-stream; name="U970055.002" Content-Transfer-Encoding: BASE64 Content-Disposition: attachment; filename="U970055.002" ICAgICAgICAgICAgICAgICAgICAgICA1QklTMjQwICAgQjEwMDAxICAgICAgICAgIEEgICBURGVi cmFoIEFubiBCZWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCRUNLNTMwIDEwICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5QklTMjQwICAgQjEwMDAxICAgICAg ICAgIEEgICA0MjMgMTIndGggU3RyZWVyIFdlc3QgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQcmluY2UgQWxiZXJ0ICAgICAgU0tTNlYzQjkgICAxMjM0ICAgICAgICAgIDEy M05CUyAgICAgICAgICAgICAgICAgICAgT04gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAyVENHMTM1ICAgMDIwOTY5MDA5NjkxMDk2OTIwOTYzMDI5NjkyMTk2 OTI1OTYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA1QklTMjQwICAgQjEwMDAxICAg ICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg --=====_34934934312BDY_===--

The community has adopted the RFC-1891.

3.3 Acknowledgement Message Format

The following is the format of the Acknowledgement message sent back to the sender of a transaction to confirm the successful receipt and decoding of a transaction. Note that there is no "Negative ACK", only a positive one.

Note that the body text "Document ACK" is present for completeness. The Message-Id is the field that is used to designate that the transaction is an ACK, and the original message id.

Example:

Received: from Test (csio.com [204.191.155.17]) by csio.com (8.8.5/8.7.5) with SMTP id VAA20098 for ; Wed, 15 Apr 1998 21:14:17 -0400 (EDT Date: Wed, 15 Apr 1998 21:14:17 -0400 (EDT) X-Mailer: AMU-Mailer To: From: Another Co. Subject: ACK-<[email protected]>[email protected] Message-Id: <"ACK- <[email protected]>"[email protected] Content-Type: text

Document ACK