New Draft: draft-besleaga-green-sustainability-wellknown-00 (Addressing Out-of-Band Environmental Reporting)

Hi GREEN Working Group,

Following discussion regarding the feasibility of per-request carbon
accounting, I have published a new significantly revised version of my
draft: *draft-besleaga-green-sustainability-wellknown-00*.

As discussed, I have moved away from the per-response header requirement to
eliminate protocol overhead and the "rebound effect." This version focuses
exclusively on an out-of-band reporting mechanism via the
/.well-known/sustainability URI.

*Key updates in this version include:*

   -

   *Discovery Model:* Historical aggregated sustainability metrics
   asynchronously (as per RFC 8615).
   -

   *Query Parameters:* Support for ?target= and ?period= to allow for
   granular reporting (e.g., specific API endpoints or daily/monthly
   aggregates) within a flat well-known namespace.
   -

   *Standardized Units:* Standardized on kWh for energy and gCO2e for
   carbon metrics to ensure interoperability.
   -

   *Formal Schema:* Included a CDDL definition to allow for automated
   parsing and validation of the JSON payload.
   -

   *Operational & Security:* Added specific considerations for caching,
   rate-limiting to prevent DoS, and fuzzing to mitigate hardware
   fingerprinting risks.

I believe this approach gives the right balance between environmental
transparency and architectural efficiency. I would appreciate feedback on
the new schema and proposed registration of the "sustainability" suffix.

*Link to the draft:*
https://datatracker.ietf.org/doc/draft-besleaga-green-sustainability-wellknown/

Best regards,
Andrei Besleaga










On Tue, Mar 3, 2026 at 11:24 AM Andrei Besleaga <andrei.besleaga@ieee.org>
wrote:

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