Re: Introducing a new HTTP response header for Carbon Emissions calculation

I enthusiastically support this idea. I disagree with the list-of-decimals
proposals - when I invoke a service I want to know how much carbon it cost,
and maybe I want the provider to reduce it; so the list of decimals would
be something that might happen behind the provider's firewall, to help them
understand contributions to the load. Do the simplest thing first.  And if
you did provide such a list, it would be more useful as a set of name/value
pairs, and then you'd have to agree on the available names and extension
mechanisms, and at least two years would have gone by. This could be
shipped in months and would be a big step forward.

Since Scope-2 talks about CO2-equivalent emissions, and the name as
proposed is REALLY LONG, maybe instead "Scope2-CO2"?

On Tue, Apr 11, 2023 at 6:26 AM Bertrand Martin <>

> Hi, (newbie here)
> I submitted a new I-D to define a simple HTTP response header field with
> the amount of CO2-eq in grams emitted by the processing of the request and
> the production of the response:
> Example:
> Carbon-Emissions-Scope-2: 0.0000456
> The goal:
> If HTTP servers are able to calculate or estimate this value, it will
> allow clients and applications to assess their Scope 3 carbon emissions. It
> is critical that we define a standard header for reporting this metric to
> help organizations assess the carbon emissions associated to the
> consumption of external services, SaaS, or even a Web site, a Google
> search, a ChatGPT response, etc.
> Note: We're talking about Scope-2 emissions only (i.e. associated to the
> electricity consumed while performing the service), because you only need
> to take into account the Scope-2 emissions of your suppliers when you
> estimate your own Scope-3 emissions. See
>  and
> for more information on Scope 1, 2 and 3.
> Any chance this would be looked at by the HTTPbis WG? I believe this could
> transform the industry in how it handles carbon emissions.
> Thank you!
> Bertrand Martin

Received on Tuesday, 11 April 2023 16:11:35 UTC