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?
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? 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)?
I only mentioned document-format-supported to draw a parallel to the specification of document-format-accepted as far as the default value (default value of document-format-supported), which differs from the specification of compression-accepted (default value of none). I wasn't intending to relate compression and document-format in other ways.
Thanks,
Michael Ziller
-----Original Message-----
From: Michael Sweet <msweet at msweet.org>
Sent: Monday, January 6, 2025 5:22 PM
To: PWG IPP Workgroup <ipp at pwg.org>
Cc: Michael Ziller <mziller at microsoft.com>
Subject: [EXTERNAL] Re: [IPP] PWG 5100.18 compression-accepted vs document-format-accepted
Michael,
> On Jan 6, 2025, at 4:42 PM, Michael Ziller via ipp <ipp at pwg.org> wrote:
>> It’s strange how PWG 5100.18 section 7.1.3 document-format-accepted defaults to the values from document-format-supported, but in 5.5.1 Fetch-Document Request, compression-accepted defaults to a value of ‘none’ rather than the values from compression-supported.
> This makes it hard to communicate –
> • A client checks compression-supported, selects one and adds a compression attribute to signify how the document was compressed
No, in this case the "compression" attribute specifies additional compression of the document data (which is typically either not already compressed or just lightly compressed), *not* the kind of compression that the document format supports (e.g. JPEG or deflate in PDF files, deflate in ZIP containers, etc.) It is analogous to the HTTP Content-Encoding header, just for the document data portion of the IPP request/response.
________________________
Michael Sweet