W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Negotiating compression

From: Michael Sweet <msweet@apple.com>
Date: Wed, 28 May 2014 13:16:35 -0400
Cc: Eliot Lear <lear@cisco.com>, "Richard Wheeldon (rwheeldo)" <rwheeldo@cisco.com>, Nicholas Hurley <hurley@todesschaf.org>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <2C80D8F1-85A6-443D-A84A-C5DE6D69F890@apple.com>
To: Johnny Graettinger <jgraettinger@chromium.org>

On May 28, 2014, at 11:58 AM, Johnny Graettinger <jgraettinger@chromium.org> wrote:
> (and in case you are wondering, yes they do TLS with 16-bit processors, it just works slowly...)
> 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).
> Forgive me as IANAE, but isn't the bit-manipulation cost from Huffman-decoding small meta-data blocks on a stream, overwhelmed by the cost of transferring gigabytes of data on that same stream over a TLS link?

Gigabytes stretched over many minutes or hours (low end printers are typically slow, too...)  And these printers offload encryption and print data processing to dedicated silicon (wouldn't be feasible otherwise).

Anyways, not all printers support encryption (like I said, we are pushing for universal TLS support but haven't gotten there yet) and anything not handled by silicon gets handled by the underpowered CPU core.

Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Wednesday, 28 May 2014 17:17:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC