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