Summary

  • RFC 3196 originally left the timing of document-data acceptance before a final Print-Job response to implementation choice; Technical Erratum 2924 replaced that latitude with a requirement that all document data be accepted first.
  • The correction concerns the final IPP success or error response. HTTP 100 Continue, early transport errors, job creation, and the later act of printing are separate events and separate evidence.

A reply that arrived too early

The Internet Printing Protocol was designed to make printing behave like a network service rather than a local cable attached to one machine. A client could submit a job over HTTP, carrying an IPP operation and, for Print-Job, the document itself. The response then returned an IPP status and job identifiers. That apparently ordinary exchange hid a question familiar to anyone who has uploaded a large object: when is the server entitled to say what happened?

RFC 3196, the November 2001 IPP/1.1 Implementer's Guide, initially gave printers room to decide whether to accept the complete document before returning the final success or error response. In 2011, Erratum 2924 replaced that sentence. It says the Printer MUST accept all document data before returning that response. The change is short, but it makes the receipt boundary part of the observable meaning of the operation. A final answer cannot race ahead of the submitted object and leave the client to guess whether the remainder was consumed.

That is the useful historical seam: not a new printer feature, but a clarification of what a final response must mean when the request includes a body that may still be in flight. RFC 2910 had described IPP's HTTP transport; RFC 2911 described its operations and job model. RFC 3196 was guidance, not a new standards-track protocol. Its erratum aligned the guide's advice with the HTTP request-body sequencing problem already visible in RFC 2616's POST and Expect/Continue rules.

Three acknowledgements, not one

The wording must not be inflated. An HTTP 100 Continue is an interim response: it tells a client it may proceed with the body. It is not the final IPP answer and does not say the print operation succeeded. HTTP can also report an early final error in circumstances where the method will not be performed; connection and body handling are transport concerns. Erratum 2924 addresses the Printer's final success or error response for the IPP request, not every possible early signal on the HTTP connection.

Nor does a successful Print-Job response mean that paper has emerged. The IPP operation can return a job-id and job-uri, giving the client a handle for later status queries. RFC 8011's job model allows the job to move through states after submission. Acceptance of document data, creation of a job, processing, marking, and delivery are different stages. Each needs its own evidence if an application is making claims about it.

This distinction matters to retries and accounting. If software sees a final response before it knows the request body crossed its defined boundary, it may not know whether to retry, whether a job exists, or whether a duplicate could be produced. Moving the final response after full receipt narrows that ambiguity. It does not promise exactly-once printing, durable storage, successful rendering, or successful delivery to a person.

A correction, not a deployment record

The record is precise about the rule and quiet about adoption. The RFC Editor records Erratum 2924 as Technical, reported by Michael Sweet in August 2011 and verified by Peter Saint-Andre in November. Neither the erratum nor the RFCs establish which products implemented it, how printers behaved in the field, or whether a particular outage resulted from the former wording. The safe claim is about protocol guidance, not an undocumented industry incident.

By 2017, RFC 8010 and RFC 8011 had replaced RFCs 2910 and 2911 with updated transport and model documents. That later IPP specification keeps the layered picture: HTTP carries an application/ipp message body; the IPP operation has its own status and job semantics; the physical device has a longer lifecycle. Reading the 2011 correction beside those later documents shows why a final response needs a defined boundary, but it does not erase the distinction between receipt and outcome.

RFC 3196's erratum is therefore a small example of infrastructure becoming legible through disciplined acknowledgements. A request is not a job merely because bytes started moving. A job is not a printed page merely because the server returned an identifier. The useful question is always: which layer has acknowledged what, and what remains unproven?

Sources

Evidence boundary

The cited standards document protocol rules and editorial history. They do not establish product adoption, measured performance, deployment prevalence, a specific failure, or that any successful response guarantees durable storage or physical output.