Zusammenfassung

  • Auch bei einem bereits verwendeten Zeichensatz verlangte RFC 2066 ein ACCEPTED; Schweigen war kein gültiger Erfolgszustand.
  • Gleichzeitige CHARSET REQUEST wurden nach Rollen aufgelöst: Der Server lehnte die Client-Anfrage ab, der Client beantwortete die Server-Anfrage.
  • Die Antwort belegte Empfang und Auswahl für nachfolgenden Text, aber nicht korrekte Bytes, fehlerfreie Übersetzung, Anwendungsverarbeitung, Authentisierung oder Sicherheit.

Ein Telnet-Endpunkt schlägt zwei Zeichensätze vor und hört danach nichts. Vielleicht nutzt die Gegenstelle bereits einen davon und schweigt nach alter Lesart. Vielleicht ging die Anfrage verloren. Vielleicht versteht die Implementierung die Subnegotiation nicht. Für den Absender haben alle Fälle dasselbe sichtbare Ergebnis: kein Beleg.

RFC 2066, im Januar 1997 als Experimental veröffentlicht, machte diese Mehrdeutigkeit nicht zum gemeinsamen Zustand. Er definierte Telnet-Option 42, CHARSET, damit Client und Server die Kodierung von Text benennen und gegebenenfalls Übersetzungstabellen austauschen konnten. Entscheidend war nicht die Länge der Zeichensatzliste, sondern die Pflicht, den Übergang beobachtbar abzuschließen.

Die Grundregel gegen Schleifen reichte hier nicht

RFC 854 organisierte Telnet-Optionen mit DO, DON'T, WILL und WON'T. Die Syntax war symmetrisch: Gleichzeitige Wünsche konnten einander als positive Bestätigung dienen. Dieselbe Symmetrie drohte jedoch endlose Bestätigungsschleifen zu erzeugen. Daher sollte eine scheinbare Bitte um einen schon aktiven Modus unbeantwortet bleiben; eine echte Zustandsänderung musste dagegen beantwortet werden.

RFC 855 trennte davon die Parameterdiskussion. Erst stimmen beide Seiten per DO/WILL zu, eine Option zu besprechen; danach werden Werte zwischen IAC SB und IAC SE verhandelt. DO CHARSET und WILL CHARSET eröffneten das Gespräch, bestimmten aber noch nicht die Kodierung des nächsten Textbytes.

RFC 2066 untersagte es, die Nichtantwort-Regel unverändert auf eine Zeichensatzanfrage zu übertragen. Sendete und erwartete der Empfänger Text bereits in einem vorgeschlagenen Satz, musste er ACCEPTED schicken und durfte die Nachricht nicht ignorieren. Die Begründung war Determiniertheit: Der Anfragende sollte nicht abwarten und aus einem Timeout folgern. Weil die positive Antwort selbst keine Antwort verlangte, entstand dadurch keine neue Schleife.

Die geordnete Liste blieb ein Angebot

CHARSET REQUEST durfte nur senden, wer DO CHARSET empfangen und WILL CHARSET gesendet hatte, unabhängig von der Reihenfolge. Die Anfrage enthielt einen oder mehrere Namen nach Präferenz. Namen ohne privaten Präfix X- mussten bei der IANA registriert sein. Der Empfänger behielt seine eigene Fähigkeits- und Präferenzentscheidung.

Vier Wege schlossen den Austausch: einen schon genutzten Satz bestätigen; einen anderen unterstützten Satz wählen; bei entsprechendem Angebot eine Tabelle senden; oder REJECTED zurückgeben, wenn kein Vorschlag möglich war. Die positive Antwort nannte einen Listenwert. Die negative bestätigte den Empfang, verweigerte aber für diese Runde alle Werte.

ACCEPTED und REJECTED beendeten die laufende Subnegotiation. Ersteres verpflichtete nachfolgenden Text auf die gewählte Kodierung, Letzteres hielt die vorgeschlagenen Kodierungen außer Kraft. Keine Antwort war ein Gesamturteil über die Software oder ein ewiges Verbot neuer Vorschläge.

Zwei Anfragen brauchten eine festgelegte Rückzugsseite

Sendeten beide berechtigten Endpunkte CHARSET REQUEST, bevor sie die Nachricht des anderen sahen, wurde Symmetrie zum Stillstand. Eine neue Anfrage war keine zulässige Antwort auf eine offene. Beide konnten ihre eigene Schlussantwort erwarten und zugleich die Anfrage der Gegenstelle festhalten.

RFC 2066 brach die Symmetrie durch Rollen. Der Server musste die Client-Anfrage negativ beantworten; der Client musste auf die Server-Anfrage reagieren. Ein Vorschlag war geschlossen, der andere konnte ACCEPTED, REJECTED oder den Tabellenpfad erreichen. Das erhöhte die Präferenz des Servers nicht. Die festen Rollen ließen beide Programme aus derselben Kollision denselben Folgezustand berechnen.

Nach Ablehnung durfte weiter verhandelt werden. Bevorzugte der Server den Satz seiner Anwendung, konnte er die Client-Liste ablehnen und selbst anfragen. Lehnte der Client auch dies ab, konnte der Server zu einer vorher angebotenen Alternative zurückkehren. Jede Runde behielt ihren eigenen Abschlussbeleg.

Die Antwort teilte den Bytestrom

Nach ACCEPTED musste der folgende Text den gewählten Satz nutzen. Während der Verhandlung sollten Daten warten und erst danach freigegeben werden. Die Antwort markierte damit die Grenze zwischen Bytes unter der alten und unter der neuen Vereinbarung.

Der Geltungsbereich war begrenzt. Übersetzung betraf Text, nicht Telnet-Befehle, und nur den BINARY-Modus. Ohne BINARY galt NVT ASCII. Für Blockterminals empfahl RFC 2066 End of Record, damit Satzgrenzen sichtbar blieben. Eine Zeichensatzwahl hob den übrigen Telnet-Vertrag nicht auf.

Auch Tabellen besaßen definierte Enden: TTABLE-ACK bestätigte den Empfang, TTABLE-NAK verlangte Wiederholung; nach wiederholtem Scheitern sollte TTABLE-REJECTED oder CHARSET REJECTED statt endloser Neuübertragung folgen.

Der Beleg war stark, weil sein Anspruch klein blieb

Ein aufgezeichnetes ACCEPTED belegt, dass die Gegenstelle eine bestimmte Anfrage erhielt und einen Namen daraus für folgenden Text wählte. Es belegt nicht die Korrektheit späterer Bytes, der Tabelle, der Dekodierung oder eines Nutzerergebnisses. REJECTED belegt Empfang und Ablehnung dieser Runde, nicht dauerhafte Unfähigkeit.

Sicherheit wurde nicht mitgeliefert. Die Security Considerations sagen lediglich, Sicherheitsfragen würden nicht behandelt. Zeichensatzverhandlung authentisiert keine Endpunkte, autorisiert keine Anwendung, verschlüsselt nichts und schützt keine Integrität. Ein deterministischer Übergang kann über einen unsicheren Kanal laufen.

Die IANA führt Option 42 weiterhin als CHARSET; RFC 2066 blieb Experimental. Das beweist Dokument und Zuteilung, nicht Einsatz. Durch Lu Hengs späteren Rahmen einer minimalen Ausgangsspezifikation lässt sich der Mechanismus als dünne gemeinsame Schicht lesen: Anfrageberechtigung, Endantworten, Bytegrenze und lokal ausführbare Konfliktregel. Das ist eine spätere redaktionelle Deutung. Die engere historische Erkenntnis lautet: Wenn Schweigen mehrere Ursachen haben kann, muss der fehlende Beleg zur Protokollnachricht werden.

Quellen