Simplifying compression requirements

[cobward]

I have some concerns about the complexity of the compression requirements:

3. The byte array is compressed using DEFLATE [RFC1951] with the
   ZLIB [RFC1950] data format. Implementations are RECOMMENDED to
   use the highest compression level available.

and

The HTTP response SHOULD use gzip Content-Encoding as defined in
[RFC9110].

The first quoted requirement adds needless complexity and computation on the part of the issuer, as compression can happen at the HTTP level (as indicated by the second requirement), so an implementation following the recommendations of this specification would end up compressing twice at the highest available compression level. With the second requirement there is ambiguity with how it interacts with the requirements in RFC9110 with respect to handling the Accept-Encoding request header.

My proposal is to remove the requirement for DEFLATE compression on internal structure, and instead rely solely on compression of the entire response using the request/response mechanism defined in RFC9110, section 8.4.

[paulbastian]

Editors Call:

• we would like have low size for other transport protocols
• we may not 100% rely on HTTP compression in cases where HTTP headers get lost, e.g. some reverse proxy configurations
• we could imagine compression_alg as an optional parameter that defaults to zlib, but could be none