The Sustainability HTTP Response Header Field

Introduction The digital economy consumes a significant and growing percentage of global electricity. Historically, assessing the environmental impact of digital services has relied on annualized, aggregate reporting, guided by standards such as the Greenhouse Gas Protocol and ISO 14064-1 . However, emerging regulatory frameworks (e.g., the EU Corporate Sustainability Reporting Directive and the Ecodesign for Sustainable Products Regulation ) and carbon-accounting standards (such as IFRS S2 and the Green Software Foundation's Software Carbon Intensity specification ) increasingly require transactional traceability. To enable real-time environmental accounting, clients and intermediaries need visibility into the carbon footprint of individual HTTP transactions. This document defines the Sustainability HTTP response header field to fulfill this need. It allows servers to transmit structured environmental metadata - such as Scope 2 and Scope 3 emissions - directly in the HTTP response. This work builds upon previous efforts to expose carbon metrics in HTTP, such as the expired Carbon-Emissions-Scope-2 draft , and complements other energy footprint APIs like CAMARA EFN and node-level exporters like Kepler .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The Sustainability Header Field The Sustainability header field is an HTTP response header that conveys the estimated environmental impact of fulfilling the request. The Sustainability header field is a Structured Field . Its value MUST be a Dictionary.

The dictionary keys represent specific environmental metrics or dimensions, and the values represent the measurements. The following keys are defined: scope-2: An sf-decimal indicating the Scope 2 carbon emissions. scope-3: An sf-decimal indicating the Scope 3 carbon emissions. unit: An sf-string indicating the unit of measurement (e.g., "gCO2e").

Example Usage A server reporting 0.005 grams of CO2 equivalent for Scope 2 and 0.12 for Scope 3 would send:

Environmental Considerations (Mitigating the Rebound Effect) Introducing new headers to the HTTP ecosystem inherently increases the bandwidth required for every transaction. If applied indiscriminately to all HTTP traffic, the energy required to transmit, process, and store this extra metadata (the "rebound effect") could exceed the environmental benefits of the transparency it provides. To mitigate this, implementers MUST adhere to the following guidelines: Header Compression: The Sustainability header relies on Structured Fields , making it highly compressible. Servers SHOULD rely on HPACK (HTTP/2) and QPACK (HTTP/3) to minimize the wire footprint of this header. Opt-In Behavior: Servers SHOULD NOT include the Sustainability header in responses by default. Clients that wish to receive this telemetry SHOULD signal their interest using an opt-in mechanism, such as the Prefer header (e.g., Prefer: return=sustainability). Proxy Aggregation: Where calculating emissions per-thread is computationally prohibitive, edge proxies or API gateways MAY inject this header based on aggregate datacenter metrics rather than forcing the backend application to calculate it dynamically.

IANA Considerations This document requests the following registration in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at https://www.iana.org/assignments/http-fields. Field Name: Sustainability Status: provisional Structured Type: Dictionary Specification document(s): This document Comments:

Security Considerations The Sustainability header field exposes internal operational metrics. While carbon metrics are generally not sensitive, highly granular, real-time reporting could theoretically allow an attacker to infer server load, backend architecture, or specific hardware configurations through timing and emission variations. Furthermore, generating accurate per-request carbon calculations may require significant CPU cycles. If a server dynamically computes this value, an attacker could intentionally request this header at a high frequency to induce a Denial of Service (DoS) or artificially inflate the server's energy consumption. Servers SHOULD cache these calculations or use aggregate approximations to mitigate this risk.