Summary

  • RFC 2351 mapped two old airline traffic families onto TCP/IP without erasing their different failure economics: Type A tolerated loss and user retry, while Type B required protected, prioritized, multi-address messaging.
  • A TCP connection and accepted MATIP session proved that two systems could exchange a declared kind of traffic. They did not prove that a seat was reserved, a ticket was issued, a retry was harmless or responsibility for a Type B message had transferred.

In 1998, an airline office could contain two technological eras at once. Its network might be moving toward cheap TCP/IP stacks and intranets, while the work on the desk still depended on terminals and host applications designed around airline protocols from the 1960s. Replacing the cable was easier than replacing the business system.

RFC 2351 addressed that mismatch with MATIP, the Mapping of Airline Traffic over Internet Protocol. The document described thousands of installed terminals, slow application migration and proprietary gateways that could not interoperate at scale. Its answer was deliberately narrow: define a common mapping between TCP and the airline application, and leave the airline application itself in place.

That narrowness preserved something more important than old character sets. It preserved two different accounts of failure.

Type A could be repeated because silence was part of its model

Type A covered interactive and host-to-host traffic, including the familiar path from an airline office or travel agency to a central reservation or ticketing computer. It was real-time, high priority and only lightly protected. RFC 2351 said it could be discarded. If no response arrived after data loss, the user could duplicate the request.

That sentence describes an operational bargain, not a universal guarantee of safe replay. A repeated availability query and a repeated sale are not necessarily the same act. The RFC did not define a transaction identifier, idempotency rule or reconciliation procedure for every airline application. It recorded that this traffic family expected a human or application to react to silence by trying again.

MATIP then preserved the machinery needed to distinguish those conversations. Type A sessions negotiated subtype, character coding, presentation, headers and multiplexing. An airline host could identify a terminal cluster through H1, H2, A1 and A2 bytes independently of the IP address. Host-to-host traffic could carry a Flow ID. The mapping made a legacy endpoint legible above TCP; it did not turn the selector into proof of who requested a booking or what the host committed.

Type B carried a different burden

Type B messaging did not need the same real-time response. It required more protection, multi-address delivery and four priority levels. RFC 2351 placed BATAP—the Type B Application to Application Protocol—above MATIP, and described BATAP as the mechanism for securing Type B traffic.

The Type B Session Open included a PROTEC field identifying the end-to-end Messaging Responsibility Transfer protocol. If the two sides named incompatible protection mechanisms, Open Confirm could reject the session. Sender and recipient High Level Designators could identify the messaging systems; alternatively, the pair of IP addresses could do so.

This is a sharper boundary than the word “reliable” suggests. A compatible PROTEC value proves that the session can use the same kind of responsibility-transfer mechanism. It is not the responsibility-transfer receipt for a particular message. A Type B data packet still has to reach BATAP or another agreed service, be accepted there, acquire whatever acknowledgement that service requires and be reconciled at the application layer.

One transport did not create one application

MATIP assigned TCP port 350 to Type A and port 351 to Type B. It required a separate TCP connection and MATIP session for each parameter set. A Session Open described the traffic; Open Confirm accepted or refused it; Session Close ended the MATIP session. No MATIP keep-alive was defined, so timeout relied on TCP.

The lifecycles overlapped without becoming identical. A MATIP session could be up only while its TCP connection was up, yet closing MATIP did not require closing TCP. A live TCP connection therefore was necessary but insufficient evidence of a live airline application session. An accepted MATIP session was necessary but insufficient evidence of a completed transaction.

That distinction matters because TCP itself keeps a lower promise. RFC 793 defined a reliable, ordered byte-stream service between processes. RFC 1122 required hosts to implement the communication layers correctly. Neither transport contract can say whether a reservation application interpreted a request, whether inventory changed, whether a ticket number was issued or whether a Type B recipient accepted responsibility.

The useful receipt chain is longer: network path, TCP establishment, MATIP Session Open, Open Confirm, permitted endpoint or flow, data delivery, application acknowledgement, responsibility transfer, business-state commit and user-visible reconciliation. Collapsing those stages turns a transport signal into commercial evidence it cannot carry.

The security warning exposed the cost of a thin bridge

RFC 2351 allowed a host to recognize an ASCU from static configuration or a user ID and password. Firewalls could filter at the IP or application layer. It said implementations might use IPsec ESP or AH, but made those protections optional. The RFC Editor now attaches a security disclaimer: static identifiers and apparent clear-text passwords are weak, while sound IPsec protection was left optional.

That warning does not erase MATIP's contribution. It clarifies its scope. The bridge reduced migration cost and standardized interoperation, but it could not manufacture authorization or cryptographic proof from legacy endpoint labels. RFC 4301 later specified a security architecture in which IPsec policy and Security Associations protect selected traffic. Even then, configured capability is not evidence that a particular exchange used the expected policy unless the operation records it.

RFC 2351 is therefore a useful piece of Internet history because it resisted an easy abstraction. IP could become common without forcing reservation queries and operational messages into one responsibility model. The network carried both. The application layers retained the duty to decide what silence, acknowledgement and completion meant.

Sources