Re: New Draft: The Sustainability Well-Know URI

Hi everyone,

I want to thank you for the suggestions and feedback provided so far
regarding the sustainability well-known URI draft.
I’ve just submitted version -04, which addresses some editorial issues
and resolves schema ambiguities and missing CHANGELOG entries
discussed previously.

Alongside the updated draft, I have also published a complete,
production-ready reference implementation to ensure the protocol is
viable for immediate adoption. This implementation acts as a Universal
Translator for all existing software that reports energy/carbon, and
it includes examples, schema validators, necessary web server
implementations, and security suggestions and configurations.

Key updates in -04 and the repository:
https://github.com/andreibesleaga/rfc-sustainability-wellknown
- New CHANGELOG listing modifications from v0 to v0.4, and updated
README documentation.
- New ADOPTION.md  -  the multi-dimensional case (technical,
regulatory, business, ecosystem, environmental) for adopting and
approving this as an RFC and IANA registration, with answers to likely
objections.
- Reference Implementation (/publisher): A fully functioning
multi-adapter Node/TypeScript application. It currently supports
direct integrations with carbon accounting platforms (Climatiq,
Watershed), enterprise ESG systems (Microsoft Sustainability Manager,
Salesforce Net Zero Cloud), and bare-metal infrastructure monitors
(Kepler-Prometheus).
- Formalized Schemas: The repository now includes rigorous JSON Type
Definition (JTD) and CDDL schemas, alongside automated validation
scripts.
- Documentation: Expanded deployment configurations (Express, Fastify,
Apache, Nginx) and discovery documentation.
- You can review the updated draft here:
https://datatracker.ietf.org/doc/draft-besleaga-green-sustainability-wellknown/
- And the full repository (including the publisher implementation and
schemas) is available for review.

I would greatly appreciate it if the WG could take a look at the
updated draft and the reference code. Does the working group have any
further feedback or technical concerns?
Additionally, given the implementation's maturity, I want to gauge the
WG's interest in formally adopting this draft, or if it must go
through the Independent track.

Thank you again for your time and guidance.

Best regards,
Andrei Nicolae Besleaga (Dipl.Eng., M.Sc.)
Independent R&D / Software Architect / Author

On Sat, Mar 21, 2026 at 12:26 PM Andrei Besleaga
<andrei.besleaga@ieee.org> wrote:
>
> 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/
>>>
>>> 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
>>>

Received on Wednesday, 24 June 2026 16:54:21 UTC