| Internet-Draft | Sustainability Header | February 2026 |
| Besleaga | Expires 31 August 2026 | [Page] |
This document defines the Sustainability HTTP response header field. This field provides a mechanism for servers to report the environmental impact and carbon footprint metrics associated with the processing and delivery of an HTTP request.¶
By defining this header as a Structured Field, this specification ensures high parsing reliability and compatibility with HTTP/2 and HTTP/3 header compression mechanisms, thereby mitigating the secondary environmental costs of transmitting the metadata itself.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 31 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
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 [GHG-PROTOCOL] and ISO 14064-1 [ISO14064-1]. However, emerging regulatory frameworks (e.g., the EU Corporate Sustainability Reporting Directive [EU-CSRD] and the Ecodesign for Sustainable Products Regulation [EU-DPP]) and carbon-accounting standards (such as IFRS S2 [IFRS-S2] and the Green Software Foundation's Software Carbon Intensity specification [GSF-SCI]) 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 [RFC9110] 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 [MARTIN-DRAFT], and complements other energy footprint APIs like CAMARA EFN [CAMARA-EFN] and node-level exporters like Kepler [KEPLER].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 [RFC8941]. Its value MUST be a Dictionary.¶
Sustainability = sf-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").¶
A server reporting 0.005 grams of CO2 equivalent for Scope 2 and 0.12 for Scope 3 would send:¶
Sustainability: scope-2=0.005, scope-3=0.12, unit="gCO2e"¶
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 [RFC8941], 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.¶
This document requests the following registration in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at https://www.iana.org/assignments/http-fields.¶
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.¶