Re: New Draft: The Sustainability HTTP Response Header Field

Hi Mark and Roy,
Thanks for taking the time to review the draft and provide such detailed
feedback.

I see the consensus that per-request accounting is infeasible and that an
out-of-band approach via .well-known URIs is preferred for
historical/aggregated data.
I will revise/change the draft to focus on making the aggregated data
discoverable via .well-known and remove the per-response header
requirement, except perhaps for a very narrow, measurable metric if one
remains viable.

Will follow up once I have a new version.

Best regards,
Andrei

On Mon, Mar 2, 2026 at 5:15 AM Roy T. Fielding <fielding@gbiv.com> wrote:

> 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
>
>