Michael,
> On Jan 8, 2025, at 9:38 PM, Michael Ziller <mziller at microsoft.com> wrote:
>> Based on RFC8011:
> compression-supported (1setOf type2 keyword)
>> This REQUIRED Printer attribute identifies the set of supported
> compression algorithms for Document data. Compression only applies
> to the Document data; compression does not apply to the encoding of
> the IPP operation itself. The supported values are used to validate
> the Client-supplied "compression" operation attributes in Print-Job
> and Send-Document requests
>> It seems that the client is allowed to compress the send-document document data using e.g. gzip if compression-supported includes gzip, and it would then add the 'compression: gzip' operation attribute to the send-document request. The INFRA printer would then store the job in the cloud and the proxy printer would do get-jobs, fetch-job, fetch-document to retrieve the job, correct?
The "compression" attribute specifies the compression applied in transit. An implementation can choose to store the document data compressed or not.
> I don't understand the intent of compression-accepted then. Say compression-supported was [gzip, deflate]. The client compressed the document (say it was originally a TXT file) to gzip data. Now if the proxy printer does a fetch-document with compression-accepted [deflate], then does this just error out?
If the Infrastructure Printer supports deflate, then the (uncompressed) document data would be re-compressed using deflate.
> And if it instead did a fetch-document and omitted compression-accepted, then does that also error out (since the infra printer only has a gzip compressed document payload)?
If you omit compression-accepted, you get uncompressed document data. The compression supplied by "compression" (from the Client or Infrastructure Printer) is simply an encoding of the document data, just like the HTTP "Content-Encoding" field.
....
The primary reason for "compression-accepted" is to allow for compression of the document data between the Infrastructure Printer and Proxy, particularly for raster data (which tends to get big rather quickly... :) And the choice of algorithms that are currently supported by IPP are those that can be implemented efficiently for memory and CPU, and that can be streamed.
I did some analysis of this back in 2010/2011:
https://ftp.pwg.org/pub/pwg/ipp/whitepaper/RasterAnalysis-20110922.pdf
We anticipated that Infrastructure Printers would be capable of doing document transforms and supporting higher-level formats for printers with more limited resources/capabilities.
________________________
Michael Sweet