Zusammenfassung

  • RFC 1921 führte auf einer Telnet-Verbindung drei adressierte Abläufe: Bildschirm 0x60, Drucker 0x68 und Bildschirmkopie 0x69; je Adresse durfte nur eine Anfrage offen sein.
  • Traf auf derselben Adresse eine zweite Anfrage ein, wurde sie gelöscht. Die Antwort PROTOCOL-VIOLATION musste dennoch bis nach der Antwort auf die erste Anfrage warten, damit Reihenfolge die fehlende Transaktionsnummer ersetzen konnte.
  • Terminaltyp, Mailbox, EOR, ACK, BUSY und READY belegten jeweils nur einen begrenzten Protokollschritt. Sie bewiesen weder Berechtigung noch Anwendungserfolg, Ausdruck oder menschliche Wahrnehmung.

Ein Ja konnte zugleich eine neue Frage sein

Ein Benutzer wollte den Bildschirminhalt auf dem örtlichen Drucker ausgeben. Der Drucker konnte jedoch zugleich vom Server benutzt werden. Der Client fragte daher mit COPY-REQ um Erlaubnis. Gestattete der Server die lokale Kopie, antwortete er mit LOCAL-COPY.

Damit war der Vorgang nicht erledigt. LOCAL-COPY gehörte zur vierten Nachrichtenart von TNVIP: response-and-request. Es beantwortete die Bitte positiv und legte zugleich eine neue Anfrage in Gegenrichtung an. Erst danach meldete der Client mit ACK, ERROR, BUSY, ABORTED, PURGED oder NOT-AVAILABLE, was in seinem begrenzten Zuständigkeitsbereich geschehen war.

Diese Form zeigt den Kern von RFC 1921, veröffentlicht im März 1996 als Informational RFC. Eine Nachricht bekam ihre Bedeutung nicht allein aus ihrem Namen oder ihrer Position im TCP-Strom. Entscheidend waren Geräteadresse, Nachrichtentyp und der gerade offene Zustand dieser Adresse.

Eine Verbindung führte drei getrennte Bücher

TNVIP war ein Telnet-Profil für Bull-VIP-Terminals. P200- und 7800-Geräte arbeiteten blockorientiert und konnten neben dem Bildschirm einen Drucker verwalten. Ein Terminal Manager stellte physischen Geräten logische Stationen und logische Geräte gegenüber; ein Drucker konnte mehreren logischen Stationen dienen.

RFC 1921 machte daraus keinen einzigen ununterscheidbaren Datenstrom. Jede TNVIP-Nachricht begann mit einem Zwei-Byte-Kopf. Das erste Byte nannte die Adresse: 0x60 für den Bildschirm, 0x68 für den Drucker und 0x69 für das Drucken einer Bildschirmkopie. Das zweite Byte enthielt den Befehl. Seine beiden niederwertigen Bits unterschieden indication, request, response und response-and-request.

Die Regel „nur eine offene Anfrage“ galt pro Adresse, nicht für die ganze Verbindung. Während eine Bildschirmanfrage auf Antwort wartete, konnte der Druckerablauf einen eigenen aktuellen Auftrag besitzen. Wer nur eine globale Sitzungsphase protokollierte, verlor deshalb die Zuordnung. Ein brauchbarer Trace brauchte mindestens Adresse, Befehl, Nachrichtentyp und den vorherigen Zustand genau dieses Ablaufs.

Andere Protokolle konnten mehrere Operationen frei verschachteln und sie mit Kennungen wieder zusammenführen. LDAP ist ein naheliegender Gegenentwurf: Message IDs tragen die Zuordnung. TNVIP verzichtete auf eine allgemeine Transaktionsnummer. Dafür begrenzte es die Parallelität und verlangte drei kleine lokale Bücher statt eines großen gemeinsamen Registers.

Die Verhandlung schuf eine Grammatik, keine Berechtigung

Bevor die TNVIP-Nachrichten galten, mussten die Gegenstellen einen Terminaltyp und Telnet End-of-Record aushandeln. Die Terminalzeichenfolge nannte ein unterstütztes Modell und konnte @Mailbox-name anhängen. Bei einem DSA-Gateway wählte diese optionale Mailbox einen bestimmten Zugangspunkt; ohne sie war ein allgemeiner Zugang möglich. Der Name war begrenzt, und Kleinbuchstaben wurden wie Großbuchstaben behandelt.

Das war eine Auswahl innerhalb der Terminalwelt des Servers, keine Anmeldung einer Person. Die Verhandlung konnte zeigen, dass beide Seiten dieselbe Modellbezeichnung verstanden. Sie bewies nicht, dass ein physisches Gerät echt, ein Benutzer authentisiert oder dieser Benutzer für die Mailbox berechtigt war. Der Abschnitt Security Considerations sagte ausdrücklich, Sicherheit werde nicht behandelt, und verwies auf spätere Authentisierung.

Optional kam Binary Transmission hinzu, wenn acht Bit benötigt wurden. Suppress-Go-Ahead war optional, wenn Telnet GA nicht zur Synchronisation mit einem DSA-Turn oder ISO-Sitzungstoken gebraucht wurde. Diese Optionen veränderten Transport und Taktung. Sie verliehen keinen Anspruch auf einen Dienst.

Auch IAC EOR blieb schmal. VIP-Kommunikation bestand aus Blöcken; EOR schloss jede TNVIP-Nachricht ab und machte ihre Grenze sichtbar. Ob der Block verarbeitet, verworfen, abgebrochen oder ausgedruckt wurde, musste eine andere Aussage liefern. Vollständige Rahmung war kein Vollzug.

Die Spezifikation riet deshalb außerdem davon ab, Telnet-Befehle mitten in eine TNVIP-Nachricht einzuschieben. Außer einem verdoppelten IAC IAC musste ein solcher Befehl zwar verarbeitet werden, doch eine Implementierung durfte dies sofort oder erst nach der aktuellen Nachricht tun. Gleiche Bytefolge konnte damit unterschiedliche Steuerreihenfolge ergeben. Befehle zwischen vollständigen Datensätzen beseitigten diese unnötige Mehrdeutigkeit.

Vier Nachrichtentypen begrenzten jede Aussage

Eine indication verlangte keine Antwort. Eine request belegte den Antwortplatz ihrer Adresse. Eine response schloss diesen Platz und gab ihn für die nächste Anfrage frei. Eine response-and-request tat beides: Sie bestätigte den bisherigen Vorgang positiv und eröffnete einen neuen in Gegenrichtung.

Darum war ACK kein universeller Beleg. Auf der Bildschirmadresse konnte es bedeuten, dass Bildschirmdaten verarbeitet worden waren, oder dass der Wechsel in den LOCAL-Zustand angenommen wurde. Die aktuelle Anfrage entschied. BUSY für den Bildschirm bedeutete, dass während LOCAL eingetroffene Daten gelöscht worden waren. Beim Drucker bedeutete BUSY, dass neue Druckdaten gelöscht wurden, weil die vorherige Druckübertragung noch nicht beendet war.

READY antwortete auf eine Abfrage des Druckerzustands. Es war nicht die Bestätigung eines Druckdatenauftrags und erst recht kein Beweis für Papier im Ausgabefach. Weitere Antworten trennten andere Fälle: ERROR für erfolglose Verarbeitung, ABORTED für Abbruch durch Bediener oder Reset, PURGED für einen noch rechtzeitig gestoppten Auftrag, NOT-AVAILABLE für ein nicht verfügbares Gerät, UNKNOWN-COMMAND für einen unbekannten Befehl und PROTOCOL-VIOLATION für eine unzulässige Reihenfolge.

Selbst Unbekanntes wurde differenziert. Eine unbekannte indication konnte gelöscht und ignoriert werden, weil niemand auf eine Antwort wartete. Eine unbekannte request verlangte dagegen eine begrenzte Antwort. Ein Betriebsprotokoll, das nur das Wort „Erfolg“ oder „Fehler“ bewahrt, löscht genau die Unterschiede, die das Protokoll absichern wollte.

Der zweite Auftrag wurde gelöscht, nicht geparkt

Solange auf einer Adresse eine Anfrage offen war, durfte keine zweite folgen. Kam sie trotzdem, musste der Empfänger sie löschen. Er durfte den Verstoß aber nicht sofort melden. Zuerst musste die Antwort auf die erste Anfrage gesendet werden; erst danach folgte PROTOCOL-VIOLATION für die gelöschte zweite.

Das Warten war keine Nachsicht. Ohne Transaktionsnummer erkannte der Sender den Adressaten einer Antwort aus der erlaubten Reihenfolge. Hätte die Fehlermeldung die ältere Antwort überholt, stünden zwei Antworten vor einem einzigen aktuellen Anfrageplatz. Die Spezifikation hätte den Fehler ehrlich benannt und zugleich die Beweiskette zerstört.

Besonders sichtbar wurde das beim Drucker. Der Client übertrug Daten in seinen Druckerpuffer und konnte keine neue Druckdatenanfrage annehmen, bevor die vorherige Operation beendet war. Früh eingetroffene Daten bekamen keinen unsichtbaren Warteplatz. Sie verschwanden und verlangten nach dem späteren Befund eine neue Entscheidung des Senders.

BUSY bedeutete daher nicht „für später vorgemerkt“. Und das zunächst ausbleibende PROTOCOL-VIOLATION bedeutete nicht Annahme. TNVIP trennte Ankunft am Telnet-Endpunkt, Zulassung in den adressierten Ablauf und gerätespezifische Verarbeitung. Diese drei Momente dürfen in einer Auswertung nicht zu einem grünen Verbindungsstatus schrumpfen.

LOCAL ließ korrekte Daten absichtlich verschwinden

Für örtliche Tests oder Konfiguration konnte der Client den ONLINE-Betrieb verlassen. Vorher sandte er eine LOCAL-STATE-Anfrage. Nach der Bestätigung sollte der Server Bildschirm- und Druckerdaten aussetzen, bis der Client mit einer ONLINE-STATE-indication die Rückkehr meldete.

Sendete der Server dennoch Daten für Bildschirm oder Drucker, löschte der lokale Client sie. Auf eine request konnte er BUSY antworten. Die TCP-Verbindung bestand, EOR konnte korrekt gesetzt sein, Adresse und Befehl konnten bekannt sein—und der vorgeschriebene Ausgang blieb Verlust.

LOCAL hielt nicht jede Kommunikation an. Vom Client ausgehende Bildschirmnachrichten und Verkehr auf anderen Adressen blieben möglich. „Das Terminal war beschäftigt“ ist deshalb zu grob. Die Sperre hatte eine Richtung, einen Gerätebereich und einen benannten Zustandswechsel.

Eine späte Löschung durfte die Vergangenheit nicht ändern

Für Bildschirm, Drucker und Bildschirmkopie gab es purge indications. Ihre Wirksamkeit hing vom Zeitpunkt ab. War die zugehörige Anfrage noch nicht bestätigt, sollte der Empfänger die Verarbeitung abbrechen und PURGED melden. War eine Antwort bereits gesendet, wurde die purge-Nachricht ignoriert und gelöscht.

Damit schützte RFC 1921 eine bereits erklärte Protokollentscheidung vor nachträglicher Umschreibung. Es versprach aber keine physische Rückabwicklung. PURGED bezog sich auf den noch abbrechbaren Verarbeitungspfad. War eine Gerätewirkung schon außerhalb dieses Pfads eingetreten, lieferte die Spezifikation keinen allgemeinen Rückholmechanismus.

Running-Code Primacy hilft als spätere Analysemethode, nicht als Behauptung über die Absicht der RFC-Autoren: Die veröffentlichte Grammatik ist nicht die Gerätewirkung. Eine implementierte Antwort ist in ihrem Zustandsautomaten real. Außerhalb seiner Beobachtungs- und Rücknahmemacht gewinnt sie keine zusätzliche Autorität.

Die Quellen belegen einen Entwurf, keine Verbreitung

RFC 1921 belegt die TNVIP-Regeln. RFC 854 beschreibt Telnet-Grundbefehle und -verhandlung. RFC 885, RFC 856, RFC 858 und RFC 1091 liefern den Kontext für EOR, Binärübertragung, Go-Ahead und Terminaltyp. RFC 1576 dokumentiert ein anderes Terminalprofil und grenzt den Gegenstand vom früheren TN3270-Artikel ab.

Diese Dokumente beweisen spezifiziertes Verhalten. Sie zählen keine Installationen, bestätigen kein konkretes Bull-Produkt, authentisieren niemanden, zeigen keinen Bildschirm und belegen keinen Ausdruck oder Erfolg einer Hostanwendung. Der Informational-Status ist Teil dieser Grenze.

Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption schärft die heutige Lesart: Der gemeinsame Zustand sollte so klein sein, dass Beteiligte ihn lokal prüfen können; Gerätepolitik und spätere Wirkungsnachweise bleiben bei denen, die sie beobachten können. Auch dies ist eine analytische Linse, kein historischer Beleg für die Motive von 1996.

Die Leistung von RFC 1921 lag in einer bescheidenen Verweigerung: Eine Antwort durfte nicht so tun, als könne sie zwei Anfragen zugleich erklären. Drei kleine Zustände, sichtbarer Verlust und geordnete Fehler machten die Aussage enger—und dadurch verwendbar.