Summary

  • RFC 2351 placed legacy airline Type A and Type B traffic above TCP, with a separate MATIP handshake for traffic characteristics and endpoint configuration.
  • A successful TCP connection and Open Confirm established a usable session envelope. They did not prove that a reservation, ticket or business message reached its final state.
  • The document's permission to repeat a Type A request after no response exposes a lasting operational problem: silence does not reveal whether the request, the reply or only the observer failed.

The telling sentence in RFC 2351 appears before its packet diagrams. Type A traffic, used for real-time queries to reservation and ticketing systems, could be discarded; when there was no response, the user could duplicate the request. The specification did not say that the first request must have failed. It described the practical action available to a person facing silence.

That silence contains several possible histories. The request may never have reached the central application. It may have arrived and been rejected. It may have changed seat inventory while the reply disappeared. The reply may have reached a gateway but not the terminal. A second request may therefore be recovery, harmless repetition or a new attempt to perform work already committed.

RFC 2351 did not invent this ambiguity. It made it visible while solving a different problem: how to carry airline-specific protocols over an IP network without replacing thousands of terminals and established central applications at once.

A common carrier for uncommon applications

Airline data networks long predated the commercial Internet. The RFC distinguishes Type A conversational and host-to-host traffic from Type B messaging. Type A served interactive work such as seat enquiries, reservations and ticket issue. Type B resembled protected asynchronous messaging, with multi-addressing and several priority levels. Their detailed business formats remained in IATA specifications and bilateral arrangements.

The attraction of TCP/IP was economic and architectural. TCP stacks were becoming inexpensive and common. Airlines could retain installed applications and terminal conventions while replacing incompatible gateway arrangements with a shared mapping. The document's RFC Editor record classifies the result as Informational, not an Internet Standard. Its historical value lies in the boundary it drew, not in a mandate it created.

MATIP sat between TCP and the airline application. Ports 350 and 351 distinguished Type A and Type B. Above the TCP connection, peers exchanged Session Open and Open Confirm so that they could agree on matters such as traffic subtype, multiplexing, header treatment, character presentation and configured terminal groups. Different parameter sets required separate sessions. Session Close ended the MATIP session, while the underlying TCP connection did not necessarily have to close.

That layering prevented one green indicator from answering every question. TCP could be connected while MATIP was not open. MATIP could be open while a particular ASCU was rejected. An ASCU could be configured while an application request was unauthorized. A payload could be accepted by the application while the business operation remained uncommitted.

Open Confirm confirmed configuration

For conversational Type A traffic, Open Confirm could refuse, accept or conditionally accept the proposed session. It could list terminal-control units that were rejected or configured. This was a useful receipt: the parties had agreed on the shape and scope of a communication session.

It was not a reservation receipt. The command carried no universal booking identity, seat-inventory version, fare commitment or ticket-accounting result. The Type A payload retained the semantics of the airline application. Host-to-host payloads were formatted according to IATA rules and bilateral agreement. MATIP transported that meaning; it did not become its final authority.

The distinction becomes sharper when a Session Open arrives on an already opened session. RFC 2351 says the existing associated configuration is cleared and replaced by the new one. A network operator can therefore observe a live TCP connection while the application-facing session identity has changed beneath it. Connection continuity is not session continuity, and session continuity is not transaction continuity.

Type B kept the same boundary. Its handshake checked that the two systems could communicate under compatible characteristics. The payload still had to conform to the accessed Type B service. An accepted session did not certify recipient-level delivery, multi-address completion or later handling by a business system.

Reliability stops at the byte stream

RFC 793 defined TCP as reliable process-to-process communication. Reliability here belongs to the ordered byte stream between endpoints. It does not assign a business meaning to the bytes, decide whether an operation is authorized or issue an airline's final receipt.

This is why a connection reset after transmission can be so difficult. TCP state may show that bytes were acknowledged by the remote stack, but the application may not have committed them. Conversely, the application may have committed before the client lost its reply. Exactly-once business execution requires an application identifier, durable state and a read-back or reconciliation path. MATIP's session identifiers and terminal addresses help route and interpret traffic; they are not automatically transaction identifiers.

The security boundary was also explicit. RFC 2351 discussed static terminal configuration, user IDs and passwords, firewalls and optional IPsec, while its published security disclaimer warned that the protocol itself did not provide adequate security. Even a protected channel would answer a narrower question than a ticket record. Confidentiality, integrity, peer admission, application permission and final outcome are different receipts.

The historical lesson is a narrow one

RFC 2351 is not evidence that a named airline deployed MATIP, that the protocol is common today or that a particular booking failed. It is evidence of how a migration could preserve old applications while standardizing the carriage between them.

Heng Lu's argument for running-code primacy helps explain why the separation matters. A negotiated label has value when independent systems can use it. It becomes misleading when the label is promoted into proof of an effect the system did not observe. His minimum-initial-specification principle points to the complementary design: standardize the smallest interoperable layer, then leave local applications responsible for the decisions and consequences that only they can see.

The Internet did not modernize airline operations by turning a TCP session into a ticket. It gave old systems a common road. The seat ledger remained elsewhere.