Re: [EXTERNAL] PWG 5100.18 compression-accepted vs document-format-accepted

Michael,

> On Jan 8, 2025, at 9:38 PM, Michael Ziller <[email protected]> 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

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp