Hello again,
I was reading about HTTP/1.1 pipelining, and wondered about whether any consideration has been paid to how this might be used in the context of IPP. Since each HTTP POST must include only one IPP operation as a payload, there seem to be times when it might be helpful, such as when using one connection as a transport to send multiple operations.
However, RFC 2616 Section 8.1.2.2 (http://tools.ietf.org/html/rfc2616#section-8.1.2) says this:
Clients SHOULD NOT pipeline requests using non-idempotent methods or
non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
premature termination of the transport connection could lead to
indeterminate results. A client wishing to send a non-idempotent
request SHOULD wait to send that request until it has received the
response status for the previous request.
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.
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?
Thanks for any thoughts,
Smith
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.