[IPP] [EXTERNAL] PWG 5100.18 compression-accepted vs document-format-accepted

[IPP] [EXTERNAL] PWG 5100.18 compression-accepted vs document-format-accepted

Michael Sweet msweet at msweet.org
Thu Jan 9 20:47:04 UTC 2025


Michael,

> On Jan 9, 2025, at 2:55 PM, Michael Ziller <mziller at microsoft.com> wrote:
> 
> Ah that makes sense. The assumption is that the infra printer is storing payloads uncompressed.

At least semantically... :)

> Thanks for the details.
> 
> -----Original Message-----
> From: Michael Sweet <msweet at msweet.org>
> Sent: Thursday, January 9, 2025 7:43 AM
> To: Michael Ziller <mziller at microsoft.com>
> Cc: PWG IPP Workgroup <ipp at pwg.org>
> Subject: Re: [EXTERNAL] [IPP] PWG 5100.18 compression-accepted vs document-format-accepted
> 
> 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
> 

________________________
Michael Sweet



More information about the ipp mailing list