New Draft: The Sustainability HTTP Response Header Field

Hello dear members of working group,

I have just submitted a new Internet-Draft proposing the "Sustainability"
HTTP response header field.

Draft:
https://datatracker.ietf.org/doc/draft-besleaga-green-sustainability-header/
<https://www.google.com/search?q=https://datatracker.ietf.org/doc/draft-besleaga-green-sustainability-header/>

As regulatory frameworks increasingly require transactional traceability
for carbon accounting, there is a growing need to stamp a precise
environmental cost onto digital transactions.

This draft defines a structured mechanism for servers to report
environmental impact metrics (such as Scope 2 and Scope 3 emissions)
associated with processing an HTTP request. To ensure high parsing
reliability and compatibility with modern HTTP/2 and HTTP/3 header
compression (HPACK/QPACK), the header is defined strictly as a Structured
Field Dictionary (RFC 8941 / RFC 9651).

I am aware that previous proposals for carbon-emission headers (e.g.,
draft-martin-http-carbon-emissions-scope-2) faced valid pushback regarding
the "rebound effect"—the concern that adding metadata to trillions of HTTP
requests could consume more energy than it saves. To address this, the
current draft mandates HPACK/QPACK compression, an opt-in behavior using
the Prefer header, and proxy aggregation where per-thread calculations are
prohibitive.

My primary question for the community is: Does this technical approach
successfully solve the rebound-effect concerns raised in previous carbon
header proposals?

I would appreciate any feedback on the suitability of this work within the
GREEN WG, or any other technical help or suggestions.

Best regards,
Andrei Nicolae Besleaga