Zusammenfassung

  • RFC 1179 dokumentierte LPD als bestehende Praxis: Ein TCP-Daemon an Port 515 nahm Befehle für benannte Druckwarteschlangen entgegen, darunter den Befehl, wartende Aufträge zu drucken.
  • Bei Receive job bestätigte der Daemon zuerst den Datei-Subbefehl. Der Client markierte danach die von ihm erklärte Bytefolge mit einem Nulloktett als vollständig; eine zweite Bestätigung folgte. Das belegt Dateiaustausch, nicht den Ausdruck einer Seite.

Ein Auftrag wechselte durch mehrere Zuständigkeiten

Ein Druckauftrag geht nicht in einem Ereignis vom Programm auf Papier über. Der Client stellt einen Antrag. Der Daemon nimmt einen Protokollschritt an. Eine Queue hält einen Auftrag vor. Ein Prozess kann gestartet werden. Eine Steuerdatei legt fest, wie eine Datendatei zu deuten ist. Erst danach kann ein Ausgabegerät etwas erzeugen. Wer alle Übergänge mit „gedruckt“ beschriftet, erhält eine bequeme Anzeige und verliert die prüfbare Geschichte.

RFC 1179 erschien im August 1990 als Informational-Dokument über ein bereits verwendetes Druckserverprotokoll. Sie ist kein Internet Standard. Ihr Gegenstand sind Befehle, Dateiformate und Antworten des Line Printer Daemon. Eine Netzantwort wird darin nicht zum Urteil über Papier, Gerätebereitschaft, Lesbarkeit oder physische Übergabe erweitert.

LPD verwendet TCP; der Daemon hört auf Port 515. Für jeden Daemon-Befehl wird eine neue Verbindung angelegt. Ein binärer Code wird vom ASCII-Namen der Queue und gegebenenfalls weiteren Operanden gefolgt. Die RFC verlangt, die Befehlsnamen als Aussagen an den Daemon zu lesen. Dass eine Anweisung angekommen ist, besagt nicht, dass der von ihr bezeichnete Zustand bereits eingetreten ist.

Das zeigt Print any waiting jobs. Der Befehl startet den Druckprozess, falls er noch nicht läuft. Er berichtet nicht, dass ein bestimmter Auftrag ausgewählt wurde, dass dessen Format verwertbar ist, dass Papier vorhanden ist oder dass eine Seite ausgegeben wurde. Er liegt zwischen Dateieingang und einer möglichen Beobachtung des Ergebnisses.

Ein Dateieingang hatte zwei Bestätigungspunkte

Nach Receive job kann der Client Subbefehle für Steuer- oder Datendateien senden. Nach jedem Subbefehl muss er die Bestätigung des Daemons abwarten. Ein Oktett aus null Bits ist positiv, jedes andere Muster negativ. Diese erste Antwort betrifft den nächsten Schritt des Austauschs, nicht den gesamten Druckauftrag.

Die Datei setzt eine weitere Grenze. Der Subbefehl enthält Bytezahl und Dateinamen. Der Client sendet diese Menge auf derselben TCP-Verbindung und übermittelt anschließend ein Nulloktett als Erklärung, dass die übertragene Datei vollständig sei. Danach ist eine zweite Bestätigung nötig. Für eine Datendatei mit angegebener Länge gilt dieselbe Struktur.

Damit bleiben drei Tatsachen getrennt: Der Daemon antwortete auf den Subbefehl; der Client erklärte die angekündigte Bytefolge für beendet; der Daemon antwortete nach dieser Grenze. Sie bilden eine nachvollziehbare Empfangskette. Keine davon misst den Ausdruck.

Auch eine passende Bytezahl legt den Inhalt nicht aus. RFC 1179 erlaubt beliebige 8-Bit-Werte in der Datendatei und weist die Interpretation der zugehörigen Steuerdatei zu. Eine Zählung beweist weder ein gültiges Druckformat noch ein erfolgreiches Rendering noch Papierausgabe.

Die Steuerdatei war eine Anweisung, kein Identitätsregister

Die Steuerdatei konnte Host, Benutzerkennung, Quelldateiname, Format und einen Mailwunsch nach dem Drucken enthalten. Solche Felder instruieren den Daemon. Sie verifizieren keine Person, kein Eigentum und keinen Empfang einer Benachrichtigung. Eine Auftragsnummer unterscheidet Einträge im begrenzten Queue-Modell, sie wird nicht zu einer dauerhaften globalen Identität.

Auch Queue-Verwaltung bleibt begrenzt. LPD konnte Queue-Zustand zurückliefern und Entfernungsbefehle mit Queue, Agent sowie Namen oder Nummern verarbeiten. Für Agenten außer root begrenzte die RFC das Löschen fremder Aufträge. Das ist eine Regel für einen lokalen Befehl, keine vollständige Aussage darüber, wer ein Dokument lesen, freigeben oder erhalten durfte.

Die historische Leistung liegt darin, die wirklich beobachtbaren Zwischenstufen zu benennen. Man kann sagen: Der Daemon nahm diesen Subbefehl an; der Client erklärte diese Bytes für vollständig; der Daemon antwortete danach; ein Start der wartenden Queue wurde angefordert. Für Druck, Übergabe oder Wirkung braucht es Belege eines weiteren Abschnitts.

Quellen