Yves: I made a comment on the issue... It's not ideal to have a content encoding for only one media type but it has been done in the past. Proosed close: satisfied.

Dan: propose close and we can close at the plenary

Peter: My first reaction is - why isn't this just a mime type and Transfer-Encoding?

Rossen: Would that work in all scenarios? For example, going through proxies etc. and coming back with the original encoding?

Peter: It should be able to send a jpg from the server, encode it into jxl along the way, transport it assuming all proxies support it and finally get decoded as jpg back in the browser.

Peter: It seems like very much an edge case for which we're trying to add a lot of overhead for very little benefit.

Lea: It's not clear if and what the savings could be compared to other encodings that are already widely used, gzip etc.

Peter: Computation cost of the encoding/decoding isn't clear. Should they need both copies on the server and rely on content negotiations?

Rossen: Let's leave a comment and move on.

Reviewd their feedback, propose closing satisfied, still not sure the result is worth the effort but not harmful. To be seen if this is more popular that simply swithing to a jxl image format and mime type.