RFC 3196, "Internet Printing Protocol/1.1: Implementor's Guide", November 2001

Errata ID: 2924
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Sweet
Date Reported: 2011-08-08
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12

Section 3.1.3.1.1 says:

The Printer object MUST return one of the following "status-code"
values for the indicated reason.  Whether all of the document data
has been accepted or not before returning the success or error
response depends on implementation.  See Section 13 in [RFC2911] for
a more complete description of each status code.

It should say:

The Printer object MUST return one of the following "status-code"
values for the indicated reason.  The Printer object MUST accept all
document data before returning the success or error response.  See
Section 13 in [RFC2911] for a more complete description of each
status code.

Notes:

HTTP (RFC 2616) classifies POST as a non-idempotent method, so a conforming server implementation may only return an error status or 100-continue as described in sections 8.1.2.2 and 8.2.2 of RFC 2616. Essentially, the printer cannot respond to the POST until it has processed all of the request message body, otherwise how would it report chunking or other protocol errors? And how would a client reliably send or a server reliably process multiple IPP requests (as POST messages) when a server provides an early response?

Report New Errata