Re: Negotiating compression

Michael,


On 5/28/14, 5:03 PM, Michael Sweet wrote:
> 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...)
>
Fair enough.  However...
> 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.

There is the design space for "HTTP" and the design space for "HTTP/2". 
We have made the assumption that they are both the same, and I have
repeatedly questioned that point.
>
> 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).

Well that's right.  Tell me why you need the additional layer of framing
in these circumstances.

Eliot