Zusammenfassung

  • RFC 1312 definierte 1992 als Experimental-Protokoll einen Kurznachrichtendienst über TCP und UDP; Empfänger- und Terminalfelder waren Lieferanweisungen, kein Nachweis einer anwesenden bestimmten Person.
  • Im TCP-Dienst bedeutete + eine erfolgreiche Lieferung an irgendeinen Benutzer oder ein Terminal. Der RFC grenzt die Aussage aber ausdrücklich auf den möglichen Aufruf eines lokalen Nachrichtenzustelldienstes ein.
  • Der Text legt nicht fest, ob die Bestätigung zur lokalen Übergabe, zur Anzeige durch ein Fenstersystem oder zur Bestätigung nach dem Schließen eines Pop-ups gehört. Ein positiver Status ist kein Beleg für Lesen.

Analyse

Eine Zielangabe war keine Beobachtung einer Person

RFC 1312 erschien im April 1992 und beschrieb einen Experimental-Dienst für eine kurze Nachricht an einen Benutzer an einem Terminal auf einem Host. Seine Nachricht bestand aus einem Revisionsoktett und nullterminierten Feldern für Empfänger, Empfängerterminal, Nachricht, Absender, Absenderterminal, Cookie und Signatur. Sie durfte insgesamt höchstens 512 Oktette umfassen. Die kleine Form ließ jedoch mehrere mögliche Ziele offen.

Ein leerer Empfänger konnte die Lieferung an jeden Benutzer des Zielsystems erlauben. War das Terminal leer, sollte das System das „richtige“ Terminal bestimmen; welche Wahl richtig war, blieb systemabhängig. Ein Stern im Terminalfeld bedeutete alle Terminals. Waren beide Felder leer, sollte die Nachricht auf eine Konsole geschrieben werden, also an einen Ort, den ein Operator oder Administrator vermutlich sieht. All das hilft einem empfangenden System bei einer Zustellung. Nichts davon misst, wer am Gerät sitzt, welche Anzeige gewählt wurde oder ob ein Inhalt wahrgenommen worden ist.

Die Unterschiede sind keine sprachliche Pedanterie. Ein Empfängername ist in diesem Zusammenhang Teil eines Antrags an einen Dienst. Ein Terminal kann durch lokale Regeln bestimmt werden. Eine Konsole wird funktional beschrieben, nicht als identifizierter Mensch. Aus der Tatsache, dass eine Maschine eine Anfrage verwalten konnte, folgt daher keine soziale Tatsache über die Aufmerksamkeit eines Menschen.

Das Plus hatte einen eng bestimmten Gegenstand

Beim TCP-basierten Dienst baut der Client eine Verbindung auf, sendet die Nachricht und erhält vom Server ein + oder , gegebenenfalls mit einer Erklärung. Plus steht für erfolgreiche Zustellung an irgendeinen Benutzer oder ein Terminal, Minus für keine Zustellung an irgendein Terminal. Das ist für den dienstinternen Zustand eine brauchbare und prüfbare Unterscheidung.

Der RFC verhindert allerdings eine größere Deutung. Eine positive Bestätigung kann nur anzeigen, dass der Message-Send-Server einen lokalen Nachrichtenzustelldienst erfolgreich aufgerufen hat. Daraus kann möglicherweise keine wirkliche Ende-zu-Ende-Semantik abgeleitet werden. Die Spezifikation schreibt nicht vor, ob die Bestätigung zur lokalen Dienstzustellung, zu einer Anzeige durch das Fenstersystem oder zu einer Benutzerbestätigung nach dem Lesen – etwa dem Schließen eines Pop-up-Fensters – gehört.

Damit nennt der Text ausdrücklich Ereignisse, die nicht gleichgesetzt werden dürfen. Der lokale Dienst kann die Nachricht annehmen, ohne dass sie angezeigt wird. Sie kann angezeigt werden, ohne dass jemand am Terminal ist. Jemand kann vor dem Terminal sitzen, ohne den Text zu lesen, ihm zuzustimmen oder darauf zu antworten. Ein + wird durch diese Beschränkung nicht wertlos. Es bleibt ein guter Nachweis für die eine Stufe, die der Server beobachtet hat. Für die anderen Stufen braucht es andere Beobachtungen.

UDP-Schweigen und Cookies beantworteten andere Fragen

Der UDP-Dienst kann ein Antwortdatagramm senden. Bei einer Nachricht an einen bestimmten Benutzer, die diesem erfolgreich geliefert wurde, soll eine positive Bestätigung folgen. Bei einer Nachricht an einen beliebigen Benutzer oder bei fehlgeschlagener Lieferung wird keine Antwort gesendet. Der RFC begründet das mit der Vermeidung eines Antwortsturms, wenn eine Broadcast-Nachricht alle Server erreicht.

Schweigen ist daher nicht einfach ein Synonym für Fehler. Es kann aus einer absichtlich begrenzten Antwortpolitik stammen. Wer das Fehlen eines UDP-Datagramms ohne weitere Angaben als unzustellbar zählt, ersetzt die Regel der Spezifikation durch eine bequemere, aber falsche Eindeutigkeit.

Das Cookie wird zusammen mit dem UDP-Quellport verwendet und soll eindeutig sein, damit ein Server doppelte Nachrichten erkennen kann. Ein Client darf dieselbe Nachricht mehrfach übertragen, um die Empfangschance zu erhöhen; der Server kann Wiederholungen verwerfen. Das ist ein Mechanismus gegen doppelte Verarbeitung innerhalb des genannten Bereichs. Er beweist weder die erste Anzeige noch die Aufmerksamkeit eines richtigen Empfängers und auch keinen Abschluss zwischen Menschen.

Eine Signaturzeile war noch keine verifizierte Identität

Ein leeres Feld SIGNATURE kann nach dem RFC die Identität des Absenders nicht überprüfen. Ist es nicht leer, handelt es sich um eine nicht zwischen Groß- und Kleinschreibung unterscheidende Textkodierung eines Sicherheitstokens. Dessen Kodierung und Bedeutung definiert die Spezifikation nicht. Das Feld bietet also Raum für ein Token, nicht für eine vollständig bestimmte Authentisierungsaussage.

Zugleich verlangt der RFC, Text zu filtern, der angezeigt werden soll. Unbefugtes Schreiben an ein Terminal und Steuerzeichen waren eigene Risiken. Auch dies trennt Ebenen, die in einem einfachen Transportpaket leicht ineinanderfallen: Absendertext, Ursprungsadresse, Token, lokale Zustellung, Ausgabefähigkeit und bestätigte Identität sind verschiedene Beweisgegenstände.

Eine kleine Bestätigung bleibt besser, wenn sie klein bleibt

RFC 1312 liefert keine Aussage über heutige Chat-, Benachrichtigungs- oder Alarmierungsprodukte. Er belegt keinen realen Leser, keine Anzeige, kein Einverständnis, keine Bereitstellung und kein Ergebnis. Als Experimental-Dokument aus dem Jahr 1992 bewahrt er vielmehr eine nützliche historische Disziplin: Ein Erfolgszeichen soll nach der Stufe benannt werden, die es tatsächlich bezeugt.

Die erfolgreiche Anrufung eines lokalen Dienstes ist eine brauchbare Tatsache. Eine sichtbare Nachricht, Aufmerksamkeit, Lesen und Reaktion sind davon getrennte Tatsachen. Werden sie nicht zu einem grünen Status zusammengezogen, bleibt sowohl die technische Zustellung als auch die menschliche Aussage prüfbar.

Quellen

RFC 1312 ist eine Experimental-Spezifikation von 1992; sie belegt weder einen realen Empfänger noch Anzeige, Lesen, Einverständnis, Identität, Einsatz oder Ergebnis.