Re: New Draft: The Sustainability HTTP Response Header Field

> On Feb 27, 2026, at 9:03 AM, Andrei Besleaga <andrei.besleaga@ieee.org> wrote:
> 
> 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
> 


I would not implement such a thing. Per-request carbon accounting is impossible. It cannot be measured or estimated with any accuracy whatsoever. To ship such a thing through additional HTTP overhead would be grossly irresponsible.

Carbon accounting requires actual measurements that are auditable. The vast majority of server-side carbon cost is spent providing for the availability of resources, not individual responses. Cost information is therefore inherently periodic and dependent on actual energy choices. The actual cost of a given request is the total cost of maintaining that resource over time, divided by the number of successful responses over that same time period.

Hence, what you are looking for is an information resource. The Web is already capable of supplying that. Estimates based on actual (per-day/month/year) costs can be supplied as its own resource (per site) or as a parallel resource tree (e.g., "/my/resource" --> "/.well-known/carbon/my/resource"). No changes to HTTP required.

....Roy