Smith,
On Mar 30, 2012, at 3:07 PM, Kennedy, Smith (Wireless Architect) wrote:
> ...
> RFC 2616 section 9.1.2 says that the POST method is non-idempotent, for understandable reasons. But in the context of IPP, it seems to me that the idempotency of the IPP operation, not the HTTP request method, that should be considered. For instance, the Get-Job-Status or Get-Job-Supported-Values operations, and even the Set-Printer-Attributes operation as well, are all idempotent as far as the Printer, Job and Subscription objects are concerned.
Because IPP is layered over HTTP and uses POST operations, all of the issues with HTTP request processing apply whether the corresponding IPP operation is idempotent or not. You just can't safely pipeline multiple IPP request messages to an IPP printer since any one of those requests may fail and close the HTTP connection (particularly for things like authentication) or otherwise return an error that you cannot (reliably) link to a particular request. And speaking of authentication, all IPP clients should be using the HTTP Expect header to elicit a 100 (continue), 401 (unauthorized), 403 (forbidden), or 426 (upgrade) response before the IPP request message and document data is sent - that also prevents pipelining from being used.
But back to your original question, we might be able to define (in IPP terms, not HTTP) certain IPP operations (like Get-Job-Attributes, Get-Printer-Supported-Values) as idempotent, but others (like Set-Printer-Attributes) specifically have side-effects that make them non-idempotent. This is one of the reasons RFC 2616 talks about HTML forms and GET vs. POST - query forms using GET are OK, but forms that cause something to change/happen have to use POST because they are not idempotent.
> Is there an official position on pipelining for IPP that overrides the recommendations for HTTP/1.1 laid out in RFC 2616 Section 8.1.2.2?
You'll find an errata to RFC 3196 (IPP Implementers Guide) on this; basically, pipelining of and early responses to POST requests are not allowed, per RFC 2616.
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.