Re: New Draft: The Sustainability Well-Know URI

Hi everyone,

​I have just uploaded version *-03* of *"The 'sustainability' Well-Known
URI"* (draft-besleaga-green-sustainability-wellknown-03).


I am unsure if the generic 'Sustainability' naming would suffice or it
should be changed to something like 'Environmental-impact' ?


​This update incorporates several feedback and other issues found. Changes
in this version include:

   - ​*Privacy Protections*: Explicit requirements for 1% noise injection
   (fuzzing) to prevent hardware fingerprinting.
   - ​*Temporal Privacy*: A new requirement that reporting granularity must
   not be finer than 24 hours to prevent real-time traffic correlation.
   - ​*Security (DoS) Mitigation*: Implementation of a 366-object cap for
   array responses and mandatory rate-limiting for query parameters.
   - ​*Schema Alignment*: Full synchronization between the JTD and CDDL
   formal definitions to ensure machine-readability.
   - ​*Energy Metrics*: Refined mandatory fields for energy-unit and
   carbon-unit to ensure global interoperability.

​The draft aims to provide a standardized, out-of-band discovery mechanism
for sustainability metrics (aligning it also with frameworks like the
EU-CSRD and the GHG Protocol).


​I would appreciate any further reviews or comments from the group.

I am also interested in discussing if the group feels this work is ready
for Working Group adoption (or it should still be a separate individual
submission or should also be in attention of other working groups ?)


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


There is also a GitHub repo for some in-progress works scripts, docs,
schemas and examples and code:
https://github.com/andreibesleaga/rfc-sustainability-wellknown


​Best regards,

​Andrei Besleaga.

On Tue, Mar 3, 2026, 11:24 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
>>
>>