Re: Negotiating compression

Eliot,

On May 28, 2014, at 8:38 AM, Eliot Lear <lear@cisco.com> wrote:
> Hi Michael,
> 
> Are the printers ones whose implementation you control?

Just indirectly through the standards I and others write.

> Also, do you have some reason to believe that they will ever go to HTTP/2?

We have been pushing hard to get TLS support in all printers, and since TLS connections have a high overhead (both for bringing the connection up and maintaining state) we are all looking at HTTP/2 to provide some savings and potentially some minor performance benefit for these printers.

But on the low end we are *very* interested in adopting HTTP/2 for IPP USB where the number of available interfaces (== number of simultaneous connections that can be supported) is typically only 2.  Right now we are multiplexing access to these interfaces using a network proxy, but that means you can't have more than 2 requests in flight...  HTTP/2 would lift that limitation, but we need to be very careful about what resources we require since the current generation of SoCs used by the vendors can't do much more than they already do (printers are complicated pieces of hardware and the lowest cost SoC is used...)

I'm aware that "we are on our own" for non-network usage of HTTP - that's fine - but I would like to keep our usage as close to the standard as is feasible, otherwise vendors can't use the same HTTP/IPP software stack for USB and network printing.

(and in case you are wondering, yes they do TLS with 16-bit processors, it just works slowly...)

> ...
> Speaking more broadly, and not really addressing Michael, as I've repeatedly said, I think this comes down to applicability of the protocol.  Quite frankly it was not designed to make printing faster or more efficient, and to the best of my knowledge nobody has tested for that case.  This is not a fault of the protocol.  Good engineers constrain their design space.  HTTP/1.1 has suffered from wild success (RFC 5218) and is well beyond its design space.  I see nothing wrong in constraining the design space, so long as what's left is useful to a significant population.

Frankly, this attitude about printing being outside the design space of HTTP is crap.  IPP is a web service, exactly as envisioned in the original HTTP specs.  Every IPP request is a POST with a message body.  The message body happens to be a binary encoded message (application/ipp) rather than XML or JSON or HTML form data, but it is exactly the same usage as any other web service and compatible with the semantics of HTTP.

The only real difference between IPP and a typical web page load is the sheer volume of data - gigabytes for a raster printer versus megabytes for a typical web page without video (you'll get gigabytes for HD video).

Rather than claiming that HTTP was never designed to support such usage after the fact, perhaps it would be more constructive to accept that HTTP *is* used for things not directly connected to a web browser or web page.  I will also point out that all versions of the HTTP specs going back to RFC 1945 (HTTP/1.0) talk about HTTP being used for more than just web browsers.  Developers didn't just decide to subvert HTTP, *they were given permission and encouraged to use HTTP as a generic communication protocol*.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair