Zusammenfassung

  • RFC 2126 hielt an TPKT Version 3 fest, um die RFC-1006-Basis zu schützen; dieselbe Versionsnummer bewies jedoch keine Einigkeit über Class 0, Class 2 oder Expedited-Optionen.
  • Gewählte Klasse, zweiter Kanal, kanalübergreifende Reihenfolge und Zustellung bei nicht-disruptivem Abbau waren getrennte Zustände mit getrennten Belegen.

Kompatibilität war in RFC 2126 kein kostenloses Gut. Die äußere Kennung blieb stabil, damit ältere Peers nicht sofort ausschieden. Gleichzeitig durfte diese Kennung weniger behaupten.

Der Proposed Standard von März 1997 führte ISO Transport über TCP für IPv4 und IPv6 fort. Class 0 verfeinerte RFC 1006; Class 2 brachte expliziten Transportabbau und neue Verfahren für Expedited Data. TPKT behielt Version 3, weil eine Änderung Implementierungen ausgeschlossen hätte, die genau diesen Wert verlangten.

Ein lesbarer Confirm konnte falsch sein

Ein alter RFC-1006-Peer beherrschte möglicherweise keine Klassenaushandlung. Der Initiator konnte Class 2 ohne Alternative anfordern und Class 0 im CC zurückbekommen. TCP war offen, das TPDU syntaktisch gültig, die Antwort dennoch nach ISO 8073 zurückzuweisen.

Die Version belegte nur die erkennbare Hülle. CR belegte die gewünschte Klasse, CC die Auswahl und die lokale Entscheidung deren Akzeptanz. Wer alles zu „connected“ verdichtete, löschte den Konflikt. Auch das reserved field sollte eingangs ignoriert werden und durfte keine inoffizielle Capability-Anzeige werden.

Ein unabhängiger Kanal war nicht automatisch synchron

Expedited Data konnte in-band reisen. Mit Forward oder Reverse Connection ließ sich eine eigene TCP-Verbindung schaffen, damit ein ausgelasteter normaler Kanal den schnellen nicht blockierte. Sie musste dasselbe Hostpaar verbinden, genau einer Transport Connection gehören und mit ihr enden.

Diese Bindung belegte den Umfang, nicht den Zeitpunkt. Beim Forward-Verfahren blieb der Aufbauzeitpunkt Implementierungsentscheidung. Zwei Sockets belegten auch keine gemeinsame Reihenfolge.

RFC 2126 unterschied deshalb Independence und Synchronisation. Forward/Reverse schuf die Unabhängigkeit. Expedited Data Acknowledgement oder Non-blocking Expedited Data konnte die Synchronisierung herstellen. Unabhängigkeit ohne Synchronisierung lockerte den ISO-Dienst und war nicht mit ISO 8072 vereinbar.

Derselbe normale Grund, zwei Pflichten

Class 0 koppelte den Transportabbau an TCP und war disruptiv. Class 2 tauschte DR und DC und bot Disruptive oder Non-Disruptive Disconnect.

Disruptive verlangte nicht, verbleibende TPDUs vor dem Schließen zu senden; DR reason 80 hex. Non-Disruptive verlangte, alle bereits dem lokalen TS-provider übergebenen TPDUs dem entfernten TS-user zuzustellen. Der reason blieb 80; Additional Information 80 kennzeichnete die stärkere Pflicht.

„Normal“ beschrieb den Vertrag also nicht vollständig. Lokale Annahme begann eine Verwahrungspflicht, war aber noch keine entfernte Zustellung.

Port und Sicherheit blieben begrenzt

TCP 102 war reserviert, aber nicht für jede Verbindung vorgeschrieben. Der IANA-Eintrag iso-tsap belegt Nummernkoordination, nicht Deployment oder Class 2. Sicherheitsfragen wurden nicht eigenständig gelöst; ITOT war laut RFC weder sicherer noch unsicherer als TCP und ISO 8073.

Lu Hengs veröffentlichte Texte dienen als offengelegte Gegenwartslinse: Claims bleiben beim beobachtbaren Running Code, eine minimale Spezifikation lässt spätere Entscheidungen offen, und symbolische Ordnung ersetzt kein ausführbares Ergebnis.

RFC 2126 zeigt daher keine misslungene Versionierung. Es zeigt einen legitimen Tausch: weniger Bruch außen, mehr Belege innen. Version, angeforderte Klasse, gewählte Klasse, Annahme, zweiter Kanal, Synchronisierung, lokale Verwahrung und entfernte Zustellung durften nicht dasselbe Feld werden.

Quellen