Zusammenfassung

  • RFC 2351 legte über TCP eine MATIP-Sitzung, in der Verkehrsart, Multiplexing, Header, Darstellung und Terminalumfang abgestimmt wurden.
  • Ein Open Confirm bestätigte eine Kommunikationskonfiguration, nicht die Reservierung eines Sitzes, die Ausstellung eines Tickets oder die endgültige Zustellung einer Type-B-Nachricht.
  • Die erlaubte Wiederholung einer Type-A-Anfrage ohne Antwort zeigt eine bleibende Beweislücke: Schweigen sagt nicht, ob Anfrage, Antwort oder nur Beobachtung ausgefallen ist.

Eine ausbleibende Antwort ist kein eindeutiges Ereignis. RFC 2351 beschreibt Type A als interaktiven Anfrage-Antwort-Verkehr für Reservierung und Ticketausstellung, der verloren gehen kann. Bleibt die Antwort aus, darf der Benutzer die Anfrage wiederholen.

Damit ist eine Handlungsregel gegeben, aber keine Zustandsdiagnose. Die erste Anfrage kann den Zentralrechner nie erreicht haben. Sie kann abgelehnt worden sein. Sie kann den Sitzbestand geändert haben, während nur die Rückantwort verschwand. Derselbe Bildschirmzustand steht für verschiedene betriebliche Realitäten.

RFC 2351 löste ein anderes Problem. In Airline-Büros standen zahlreiche Terminals und Anwendungen aus einer Zeit vor TCP/IP. Eine sofortige Ablösung war weder wirtschaftlich noch operativ realistisch. MATIP sollte diese Protokolle über ein gemeinsames IP-Transportmittel führen, statt weitere nicht interoperable Gateways zu schaffen.

Standardisierte Beförderung, nicht standardisierte Entscheidung

Type A umfasste interaktive Gespräche und Host-zu-Host-Verkehr. Type B war Nachrichtenverkehr mit höherem Schutzbedarf, mehreren Adressaten und vier Prioritäten. Die eigentlichen Fachformate blieben bei IATA-Regeln und bilateralen Vereinbarungen.

MATIP lag zwischen TCP und der Airline-Anwendung. Die Ports 350 und 351 trennten Type A und Type B. Nach dem TCP-Aufbau handelten Session Open und Open Confirm Untertyp, Multiplexing, Header, Zeichendarstellung und gegebenenfalls ASCU-Gruppen aus. Unterschiedliche Parametersätze verlangten getrennte Sitzungen.

Der RFC-Editor-Eintrag führt das Dokument als Informational. Es war kein verpflichtender Internetstandard und kein Einsatzbericht. Es definierte eine gemeinsame Grenze, an der zwei vorhandene Systeme ihre Transportannahmen austauschen konnten.

Diese Grenze ließ mehrere Zustände zu. TCP konnte verbunden sein, obwohl MATIP geschlossen war. MATIP konnte die Sitzung annehmen und einzelne ASCU ausschließen. Eine konfigurierte Einheit konnte für eine Anwendungshandlung unberechtigt sein. Eine Anwendung konnte Daten annehmen, ohne das Geschäftsergebnis bereits dauerhaft zu speichern.

Was die Bestätigung tatsächlich bestätigte

Im dialogorientierten Type A konnte Open Confirm ablehnen, vollständig annehmen oder bedingt annehmen. Die Antwort konnte konfigurierte oder fehlerhafte ASCU nennen. Das war ein belastbarer Sitzungsbeleg.

Es war kein Reservierungsbeleg. Es gab darin keine allgemeine Buchungskennung, keine Bestandsversion, keine Tarifbindung und keinen Ticketbuchungssatz. Die Nutzlast erhielt ihre Bedeutung aus der Airline-Anwendung. MATIP übernahm ihre Beförderung, nicht ihre abschließende Auslegung.

Bemerkenswert ist auch die Behandlung eines neuen Session Open in einer bereits offenen Sitzung: Die zugehörige Konfiguration wird gelöscht und durch die neue ersetzt. Die TCP-Verbindung kann weiter bestehen, während sich der betriebliche Umfang ändert. Transportkontinuität beweist weder Sitzungskontinuität noch Transaktionskontinuität.

Für Type B galt eine ähnliche Trennung. Die Sitzung prüfte, ob beide Systeme mit kompatiblen Merkmalen kommunizieren konnten. Die Nachricht musste weiterhin den Regeln des angesprochenen Dienstes entsprechen. Angenommene Sitzung und Zustellung an den endgültigen Empfänger waren nicht dasselbe Ereignis.

Zuverlässig ist, was TCP tatsächlich beobachtet

RFC 793 beschreibt TCP als zuverlässigen, geordneten Bytestrom zwischen Prozessen. Ein TCP-Acknowledgement betrifft diesen Strom. Es erteilt keine fachliche Berechtigung und schreibt keinen Sitz in ein Inventar.

Nach einem Abbruch können Bytes von der entfernten TCP-Instanz bestätigt worden sein, ohne dass die Anwendung sie festgeschrieben hat. Umgekehrt kann die Anwendung festgeschrieben haben, bevor die Antwort verloren ging. Genau-einmal-Verhalten auf Fachebene braucht eine dauerhafte Transaktionskennung, gespeicherten Zustand und eine Rücklesemöglichkeit. IP-Adresse, ASCU und MATIP-Sitzung sind nicht automatisch solche Schlüssel.

Auch Sicherheit bildet eine eigene Kette. RFC 2351 nennt statische Konfiguration, Benutzerkennung und Passwort, Firewalls und optionales IPsec. Der veröffentlichte Sicherheitshinweis erklärt zugleich, dass das Protokoll Sicherheitsfragen nicht ausreichend löst. Kanalschutz, Gegenstellenzulassung, Anwendungsautorisierung und Ergebnisbeweis bleiben getrennt.

Historische Evidenz ist kein heutiger Einsatznachweis

Die Quellen belegen weder den Einsatz bei einer bestimmten Fluggesellschaft noch eine verbreitete Nutzung im Jahr 2026 oder einen realen Vorfall. Sie belegen eine Architektur, die den Transport modernisierte, ohne die Zuständigkeit der Anwendung unbemerkt zu verschieben.

Lu Hengs Forderung nach Vorrang laufender Implementierung liefert dafür einen Maßstab: Ein gemeinsames Signal ist so stark wie das, was unabhängige Systeme tatsächlich prüfen können. Wird aus „Sitzung angenommen“ die Behauptung „Ticket ausgestellt“, erhält das Symbol mehr Macht als die Ausführung. Das Prinzip einer minimalen Anfangsspezifikation hält die gemeinsame Schicht klein und belässt lokale Entscheidungen bei ihren Trägern.

RFC 2351 öffnete alten Airline-Systemen die IP-Straße. Den Sitzbestand verwaltete weiterhin das Zielsystem.