Zusammenfassung

  • RFC 3196 überließ es zunächst den Implementierungen, ob sie vor der endgültigen Print-Job-Antwort sämtliche Dokumentdaten annahmen. Das technische Erratum 2924 beendete diesen Spielraum: Erst müssen alle Daten angenommen sein.
  • Die Vorgabe betrifft die endgültige IPP-Erfolgs- oder Fehlerantwort. HTTP 100 Continue, ein früher Transportfehler, die Anlage eines Jobs und der physische Ausdruck sind getrennte Ereignisse.

Die Antwort vor dem Dokument

Das Internet Printing Protocol (IPP) sollte Drucken als Netzwerkdienst nutzbar machen. Ein Client übermittelte eine Operation per HTTP; bei Print-Job lag das Dokument ebenfalls im Request-Body. Der Drucker lieferte einen IPP-Status und gegebenenfalls Kennungen zurück, über die sich ein Job später abfragen ließ. Hinter diesem routinemäßigen Ablauf stand eine grundlegende Frage: Wann darf der Server das Ergebnis einer Anfrage melden, deren Inhalt noch unterwegs ist?

RFC 3196, der im November 2001 veröffentlichte IPP/1.1 Implementer's Guide, ließ anfangs offen, ob der Drucker das vollständige Dokument vor seiner endgültigen Erfolgs- oder Fehlerantwort entgegennahm. Erratum 2924 änderte den Satz 2011: Der Drucker MUSS alle Dokumentdaten annehmen, bevor er diese Antwort zurückgibt. Das führte keine neue Druckfunktion ein. Es legte fest, was eine endgültige Antwort bedeuten darf, wenn der Request-Body noch übertragen wird.

Bei gestreamten Uploads ist das besonders wichtig. Meldet die Anwendung schon ein Ergebnis, während noch Daten gesendet werden, kann der Client kaum wissen, ob der Rest angekommen ist, ein Job existiert oder ein erneuter Versuch Duplikate erzeugt. Für die endgültige IPP-Antwort verlagert das Erratum diese Unsicherheit zum Drucker: vollständiger Empfang zuerst, finale Antwort danach.

Drei Bestätigungen mit verschiedener Aussage

Der Geltungsbereich ist begrenzt. HTTP 100 Continue ist eine vorläufige Antwort: Der Client darf mit dem Body fortfahren. Sie besagt nicht, dass die IPP-Operation erfolgreich war. HTTP kann in Fällen, in denen die Methode nicht ausgeführt wird, auch früh eine endgültige Fehlerantwort senden; der Umgang mit Body und Verbindung ist eine separate Transportfrage. Das Erratum macht nicht jedes frühe Signal zum Regelverstoß.

Auch eine erfolgreiche Print-Job-Antwort beweist nicht, dass Papier ausgegeben wurde. Sie kann job-id und job-uri liefern, damit der Client den weiteren Status abfragt. RFC 8010 und RFC 8011 aktualisierten 2017 RFC 2910 und RFC 2911 und halten Transport, IPP-Operation und Job-Lebenszyklus auseinander. Dokumentempfang, Jobannahme, Verarbeitung, Druck und Übergabe an eine Person sind verschiedene Stationen.

Die Quellen belegen die Korrektur, aber nicht ihre Verbreitung. RFC 3196 ist ein Informational-Dokument und keine neue Standards-Track-Protokollspezifikation. Der RFC Editor führt Erratum 2924 als Technical; Michael Sweet meldete es im August 2011, Peter Saint-Andre bestätigte es im November. Daraus folgt nicht, welche Produkte die Korrektur umsetzten oder ob ein konkreter Ausfall auf den alten Text zurückging. Eine solche Incident-Erzählung wäre unbelegt.

Die belastbare Lehre lautet daher: Welche Schicht hat genau was bestätigt? Der Beginn eines Transfers beweist keinen vollständigen Dokumentempfang. Eine Jobkennung beweist keinen Ausdruck. Das Erratum schließt eine eng umrissene Mehrdeutigkeit, nicht alle Unsicherheit im weiteren Ablauf.

Quellen

Die Primärquellen dokumentieren Regel und Korrekturgeschichte, nicht Produktübernahme, gemessene Leistung, Verbreitung, einen konkreten Vorfall oder dauerhafte Speicherung beziehungsweise physischen Ausdruck.