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

This feels like it should be an IPv6 EH honestly. Why not just move away
from HTTP to avoid reporting these, and then just cite "technological
limitations"? Bonus points for requiring IPv6, as that would wedge in a
demand to go IPv6-only to satisfy regulations.

On Thu, Apr 13, 2023, 06:01 Bertrand Martin <>

> > -----Original Message-----
> > From: Mark Nottingham <>
> > Sent: Tuesday, April 11, 2023 4:16 PM
> >
> > > On 12 Apr 2023, at 12:10 am, Lucas Pardue <>
> > wrote:
> > >
> > > Have you considered how this might work where there is a chain of
> servers
> > involved in handling a request? We might think of CDNs in this light but
> it is
> > also common for servers to sit in front of something like an app server
> or cache
> > server. Therefore it could benefit this proposal to make it a list of
> values that
> > can comprise the entire lifecycle of a request/response exchange.
> >
> > I had the same thought. It's probably best specified as a List of
> Decimals; see:
> >
> List of decimals would allow more details about carbon emissions for each
> server in the chain. However, proxies that rely on their cache would need
> to update the value with their own and thus remove the entire list. Also,
> clients won't need the details on the chain. When calculating Scope 3
> carbon emissions, you need the Scope 2 value for the entire supply chain,
> and not just one step. So if we consider the actual use case, a single
> value is probably better, imo.
> > But, I also wonder if the response is the best place to put this
> information -- it
> > only makes it available after the fact, and scatters information that
> needs to be
> > aggregated for many use cases. More discussion / description of the use
> cases
> > would help guide the design.
> The use case is to allow applications and clients to calculate their Scope
> 3 carbon emissions as per GHG Protocol definition. Laws are put in place
> (slowly) around the world requiring organizations to produce an annual
> report on their carbon emissions, including Scope 3. Organizations relying
> heavily on IT and digital services need proper instrumentation to calculate
> the carbon emissions associated to their IT. When using only on-prem
> servers, one could simply use the electricity bill to calculate the carbon
> emissions of a data center. But most organizations use public cloud
> services and SaaS platforms heavily. As of now, their no proper way for a
> client to estimate the carbon emissions associated to the usage of
> Atlassian Jira services for example, or GitHub. If the IETF defines a
> standard for reporting carbon emissions associated to an HTTP
> request/response, it will allow organizations to estimate the carbon
> emissions associated to all Web services. Clients will pressure providers
> to expose this information and implement the standard. Without a standard,
> vendors and service providers are likely to come up with unsatisfactory
> solutions, like AWS who provides an estimation of carbon emissions every
> quarter only... on your invoice!
> > E.g., if the client is an API consumer and their use case is informing
> their
> > request patterns, it's likely better to get this sort of hint from a
> description
> > (e.g., OpenAPI) rather than in responses.
> As of now, the need of the "market" is to get this information: scope 2
> carbon emissions. In the future, we may want to get this information
> beforehand, introduce a negotiation mechanism, or quotas, etc. but at this
> stage, this is science fiction, unfortunately: no server is able to respond
> to such request (predict carbon emission of a request, or do not exceed
> quotas).
> > That doesn't mean you shouldn't define the header, of course -- just
> that it
> > might not be useful on its own. Also, adding headers to responses does
> ever-
> > so-slightly increase carbon emissions...
> True! it's the observability vs "green coding" debate...
> >
> > Cheers,
> >
> > --
> > Mark Nottingham

Received on Thursday, 13 April 2023 09:20:07 UTC