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

> -----Original Message-----
> From: Mark Nottingham <mnot@mnot.net>
> Sent: Tuesday, April 11, 2023 4:16 PM
> 
> > On 12 Apr 2023, at 12:10 am, Lucas Pardue <lucaspardue.24.7@gmail.com>
> 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:
>   https://httpwg.org/specs/rfc8941.html

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   https://www.mnot.net/

Received on Thursday, 13 April 2023 09:00:40 UTC