Zusammenfassung

  • Das Network Virtual Terminal legte nur die gemeinsame Darstellung fest: CR LF bezeichnete eine neue Zeile, CR NUL den Wagenrücklauf ohne Zeilenvorschub; ein nacktes CR war im normalen NVT-ASCII unzulässig.
  • Das Byte nach CR schloss eine lokale Prüfentscheidung. Sender und Empfänger behielten dennoch die Hoheit über ihre jeweilige Abbildung zwischen NVT und Betriebssystem.
  • RFC 1123 präzisierte später die Enter-Taste, der ausgehandelte Binary-Modus schaltete die Zeilenumsetzung ab, und Net-Unicode behielt CRLF, empfahl aber gegen CR NUL.

Ein Zeichen mit offenem Ausgang

Im Druckermodell des NVT führt CR an den linken Rand derselben Zeile. LF bewegt vertikal zur nächsten Zeile und lässt die horizontale Position stehen. Die Folge CR LF vereinigt beide Bewegungen zur Funktion „neue Zeile“.

Reale Geräte und Betriebssysteme teilten diese Mechanik nicht. Manche verbanden beide Bewegungen fest, andere verwendeten nur LF oder nur CR als lokalen Abschluss, wieder andere arbeiteten mit Längen oder Record-Grenzen. Würde ein Empfänger CR sofort ausführen, könnte ein folgendes LF zu einer falschen Doppelbehandlung führen. Würde er stets warten, fehlte einem echten einzelnen Wagenrücklauf ein Ende.

RFC 318 formulierte 1972 die Lösung: CR zunächst festhalten und genau ein Zeichen weitersehen. LF wählt die neue Zeile. Soll CR allein gelten, sendet die Gegenstelle CR NUL. NUL bewirkt am virtuellen Drucker nichts, beendet aber die Zweigentscheidung.

Das Nullzeichen war in dieser Stellung kein bedeutungsloser Füllstoff. Es erklärte verbindlich, dass kein LF zum vorherigen CR gehört.

Ein schmales gemeinsames Terminal

RFC 854 setzte das Network Virtual Terminal als Ausgangszustand jeder Telnet-Verbindung. Beide Seiten bildeten lokale Geräte und Prozesse auf ein begrenztes Zwischenmodell ab. Keine musste die vollständigen Eigenschaften der anderen kennen.

NUL war eine No Operation, LF eine vertikale Bewegung, CR die Rückkehr zur linken Marge. Breite, Seitenlänge, Zeichensatzumsetzung und lokale Treiber blieben Sache der Endpunkte. Zentralisiert wurde nur, was beide zum Verstehen derselben Folge brauchten.

Beim kritischen Fall wurde die Regel zwingend. CR LF musste als ein New-Line-Zeichen behandelt werden; CR NUL stand für den Wagenrücklauf allein; CR war im normalen NVT-ASCII in anderen Zusammenhängen zu vermeiden. Das galt in beide Übertragungsrichtungen.

Nach Empfang von CR NUL entfernte Telnet das NUL, bevor die NVT-Aktion in den lokalen Zeichensatz überführt wurde. Das Byte gehörte zum Darstellungsvertrag dieser Schicht. Daraus folgt keine Erlaubnis, NUL in jedem anderen Datenstrom zu verwerfen.

Enter war eine lokale Absicht, kein Drahtsymbol

Die klare Ausgabesemantik beantwortete nicht vollständig, was ein User Telnet beim Drücken von Return oder Enter senden sollte. Ging es um die Funktion „Zeile abschließen“ oder um das Zeichen CR eines ASCII-Terminals?

RFC 1123 dokumentierte die Folge: Manche Clients sendeten CR LF, andere CR NUL. Ein korrektes ASCII-Server-Telnet musste beiden Folgen bei Terminaleingabe dieselbe Wirkung wie der lokalen Zeilenendetaste geben. Für Nicht-ASCII-Hosts blieb ein Dilemma: Diese Gleichsetzung konnte die Eingabe eines echten alleinstehenden CR unmöglich machen.

Die Präzisierung trennte Rollen. Ein Client musste CR LF, CR NUL und LF senden können. Auf einem ASCII-Host sollte er eine nutzergesteuerte Wahl bieten und CR LF für die Zeilenendetaste voreinstellen. Bei Serverausgabe und anderem, durch Telnet getragenem Protokolltext war CR LF als Zeilenende vorgeschrieben.

Der Server übersetzte anschließend in seine lokale Terminalwelt. Im Raw-Modus konnte die Anwendung CR erhalten; im formatierten Modus galt die lokale Zeilenkonvention. Gefordert war gleiche Wirkung am Terminalrand, nicht identische Speicherung in jedem internen Puffer.

Binary wechselte den zuständigen Parser

Die Binary-Option aus RFC 856 musste für jede Richtung gesondert ausgehandelt werden. Erst Anfrage und Bestätigung änderten die Interpretation. Gewöhnliche Oktette wurden zu Achtbitdaten; IAC blieb dennoch Kommandoeinleitung und musste für den Datenwert 255 verdoppelt werden.

RFC 1123 stellte klar, dass Binary die Zeilenendverarbeitung abschaltet. CR durfte weder durch CR NUL noch durch CR LF ersetzt werden. Der Modus erweiterte also nicht bloß NVT um ein achtes Bit; er entzog dem NVT-Formatierer die Zuständigkeit.

Wer NUL nach CR ohne Kenntnis des Zustands entfernt, kann Text scheinbar bereinigen und Binärdaten beschädigen. Auch Einfügen aus vermeintlicher Vorsicht verändert die Nutzdaten. Richtung und ausgehandelter Zustand sind Teil der Beweisgrundlage.

Linemode verschob Arbeit, nicht Bedeutung

RFC 1184 verlegte bei aktiviertem EDIT die Zeilenbearbeitung zum Client. Das sparte Zeichen-für-Zeichen-Rundreisen auf langsamen Verbindungen. Ein normaler lokaler Abschluss wurde als CR LF gesendet.

Ohne EDIT ging carriage return als CR NUL, line feed als LF und eine nicht auf ein einzelnes ASCII-Zeichen abbildbare Fertig-Taste als CR LF. Für seine Ausgabe blieb der Server zuständig: CR LF für neue Zeile, CR NUL für Rücklauf allein, LF für den Vorschub allein.

Der Ort der Bearbeitung konnte sich aus Leistungsgründen ändern, ohne dass der Client die Bedeutung fremder Ausgabe übernahm. Lokalisierung der Arbeit und Autorität über Semantik blieben getrennt.

Unicode erbte die Linie und verengte die Ausnahme

RFC 5198 ordnete NVT-ASCII historisch in Net-Unicode ein. UTF-8 wurde zum Zeichenformat, CRLF blieb die Darstellung von Zeilenenden. Auch die strukturelle Forderung, dass CR unmittelbar von LF oder NUL gefolgt sein muss, blieb bestehen.

CR NUL wurde nun jedoch abgeraten. Moderne Kombination und Markup ersetzten viele Überdruck- und Layouttricks; zugleich kann NUL in Programmiersprachen als Stringende wirken. Ein ehemals sinnvoller Sonderfall wurde für allgemeinen Text zum Risiko.

Das ist keine rückwirkende Widerlegung. Die gemeinsame Abstraktion änderte sich, und damit trennte sich dauerhaft notwendige Kompatibilität von einem auslaufenden Druckereffekt.

Das IANA-Register der Telnet-Optionen führt Binary, Linemode und Carriage-Return-Optionen weiter. Es belegt Codes und Referenzen, keine heutige Verbreitung oder Produktkonformität.

Normalisierung ohne Zuständigkeit

Die Verteilung war absichtlich dezentral: Der Sender wählte eine NVT-Aktion, der Empfänger prüfte sie am Folgebyte und übersetzte lokal; ein anderer Interpreter wurde nur durch Aushandlung aktiv.

Fehler entstehen, wenn Zwischenstufen vorzeitig handeln. Ein Gateway vereinheitlicht alle Zeilen, eine Stringbibliothek endet am NUL, ein Client setzt Enter immer mit Newline gleich, ein Log speichert nur sichtbare Ausgabe. Danach lässt sich die verworfene Entscheidung nicht aus Absichten rekonstruieren.

Quellen und Evidenzgrenzen

Die Dokumente belegen Modell, Klarstellungen, ausgehandelte Grenzen und registrierte Begriffe. Sie messen keine aktuelle Nutzung, zertifizieren keine Implementierung und beweisen keine historische Einheitlichkeit. CR NUL wird nur innerhalb seiner festgelegten Richtung, Funktion und Betriebsart bewertet.