The 'sustainability' Well-Known URI
draft-besleaga-green-sustainability-wellknown-00

GREEN                                                     A. N. Besleaga
Internet-Draft                                               Independent
Intended status: Informational                             15 March 2026
Expires: 16 September 2026

                  The 'sustainability' Well-Known URI
            draft-besleaga-green-sustainability-wellknown-00

Abstract

   This document defines the "sustainability" well-known URI.  This URI
   provides a standardized, out-of-band mechanism for web servers and
   digital services to publish their aggregated environmental impact,
   energy consumption, and carbon footprint metrics.

   By utilizing an asynchronous reporting model, this approach allows
   for transparent environmental accounting without the bandwidth and
   energy overhead associated with per-request HTTP headers.

Status of This Memo

   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 16 September 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Besleaga                Expires 16 September 2026               [Page 1]
Internet-Draft        Sustainability Well-Known URI           March 2026

   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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  The "sustainability" Well-Known URI . . . . . . . . . . . . .   3
     2.1.  URI Definition  . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Query Parameters  . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Payload Format  . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  *Example Usage* . . . . . . . . . . . . . . . . . . . . .   4
       2.4.1.  Standardized Units  . . . . . . . . . . . . . . . . .   5
       2.4.2.  Formal Definition (CDDL)  . . . . . . . . . . . . . .   5
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
     3.1.  Caching . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security and Privacy Considerations . . . . . . . . . . . . .   6
     4.1.  Traffic Analysis and Replay . . . . . . . . . . . . . . .   6
     4.2.  Hardware Fingerprinting . . . . . . . . . . . . . . . . .   6
     4.3.  Denial of Service (DoS) . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The digital economy consumes a significant and growing percentage of
   global electricity.  Emerging regulatory frameworks, such as the EU
   Corporate Sustainability Reporting Directive (CSRD) [EU-CSRD], and
   industry standards like the Green Software Foundation's Software
   Carbon Intensity [GSF-SCI] and the W3C Web Sustainability Guidelines
   [W3C-WSG], increasingly require organizations to disclose the
   environmental impact of their digital services.

Besleaga                Expires 16 September 2026               [Page 2]
Internet-Draft        Sustainability Well-Known URI           March 2026

   These transparency efforts directly align with the 2030 Agenda for
   Sustainable Development adopted by the United Nations [UN-SDG],
   specifically supporting Target 7.3 (doubling the global rate of
   improvement in energy efficiency), Target 9.4 (upgrading
   infrastructure to make them sustainable), and Target 12.6
   (encouraging companies to integrate sustainability information into
   their reporting cycles).

   While initial proposals for carbon transparency focused on per-
   request HTTP headers, such methods introduce a "rebound effect" where
   the metadata itself increases the carbon footprint of the
   transaction.  Additionally, caching and TTFB (Time-To-First-Byte)
   performance are negatively impacted by dynamic carbon header
   generation.

   This document leverages [RFC8615] to define a /.well-known/
   sustainability URI, allowing servers to publish periodic, aggregated
   environmental metrics out-of-band.

1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  The "sustainability" Well-Known URI

2.1.  URI Definition

   The URI suffix "sustainability" is registered in the Well-Known URI
   Registry.  A client requests sustainability metrics by issuing an
   HTTP GET request to /.well-known/sustainability.

2.2.  Query Parameters

   To maintain a flat namespace within .well-known, servers SHOULD
   support optional query parameters for granularity:

   *  *target*: Specifies the resource path (e.g., ?target=/api/v1/
      search).

   *  *period*: Specifies the timeframe using [RFC3339] formats:

      -  Yearly: YYYY

      -  Monthly: YYYY-MM

Besleaga                Expires 16 September 2026               [Page 3]
Internet-Draft        Sustainability Well-Known URI           March 2026

      -  Daily: YYYY-MM-DD

   If no parameters are provided, the server SHOULD return the most
   recently completed reporting period (e.g., the previous month or the
   previous day), or a default aggregate defined by the server's policy.

   Alternatively, servers MAY support start and end query parameters to
   define a custom bounded timeframe, using complete [RFC3339] date-time
   strings.

2.3.  Payload Format

   A successful response to a request for a sustainability well-known
   URI MUST return a JSON object [RFC8259] with the media type
   application/json.

   The JSON object MAY contain the following keys to align with the
   [GHG-PROTOCOL] and European Sustainability Reporting Standards (ESRS
   E1):

   *  reporting-period: A string indicating the time period the metrics
      cover.

   *  energy-consumption: A numerical value indicating the total energy
      consumed by the host or resource during the reporting period.

   *  energy-unit: A string indicating the unit of energy (e.g., "kWh").

   *  scope-1: A numerical value indicating the estimated Scope 1
      (direct) carbon emissions.

   *  scope-2: A numerical value indicating the estimated Scope 2
      (indirect/purchased energy) carbon emissions.

   *  scope-3: A numerical value indicating the estimated Scope 3 (value
      chain) carbon emissions.

   *  carbon-unit: A string indicating the unit of carbon measurement
      (e.g., "gCO2e" or "kgCO2e").

   *  sci-score: A numerical value indicating the Software Carbon
      Intensity (SCI) score.

2.4.  *Example Usage*

   An auditor requesting the daily metrics for a specific date:

   HTTP

Besleaga                Expires 16 September 2026               [Page 4]
Internet-Draft        Sustainability Well-Known URI           March 2026

   GET /.well-known/sustainability?period=2025-10-15 HTTP/1.1
   Host: api.example.com
   Accept: application/json

   Response:

   HTTP

   HTTP/1.1 200 OK
   Content-Type: application/json
   Cache-Control: max-age=86400

   {
   "reporting-period": "2025-10-15",
   "energy-consumption": 14.5,
   "energy-unit": "kWh",
   "scope-1": 0.0,
   "scope-2": 0.4,
   "scope-3": 2.1,
   "carbon-unit": "kgCO2e",
   "sci-score": 4.2
   }

2.4.1.  Standardized Units

   To ensure interoperability: * *Energy*: Values MUST be reported in
   kilowatt-hours (kWh). * *Carbon*: Values MUST be reported in grams of
   CO2 equivalent (gCO2e).

2.4.2.  Formal Definition (CDDL)

   The following Concise Data Definition Language (CDDL) [RFC8949]
   describes the response:

   cddl sustainability-report: { "reporting-period": tstr "energy-
   consumption": number "energy-unit": "kWh" "scope-1"?: number "scope-
   2"?: number "scope-3"?: number "carbon-unit": "gCO2e" "sci-score"?:
   number }

3.  Operational Considerations

Besleaga                Expires 16 September 2026               [Page 5]
Internet-Draft        Sustainability Well-Known URI           March 2026

3.1.  Caching

   Because this endpoint may require internal database queries to
   aggregate data - especially when dynamic period or start/end query
   parameters are utilized - it could become a vector for Denial of
   Service (DoS) attacks.  Hosts SHOULD implement heavy caching (e.g.,
   Cache-Control: max-age=86400) for the .well-known responses, and
   enforce strict rate-limiting on requests containing time-range query
   parameters.

   Servers SHOULD use the Cache-Control header to prevent redundant
   requests.  For historical data (e.g., a daily report for a previous
   date), a long max-age (e.g., 31536000 for one year) is RECOMMENDED.

4.  Security and Privacy Considerations

4.1.  Traffic Analysis and Replay

   Aggregated metrics reduce the risk of traffic analysis.  However,
   real-time telemetry is NOT RECOMMENDED as it could allow an attacker
   to correlate energy spikes with specific user actions.

4.2.  Hardware Fingerprinting

   Precise energy metrics can reveal underlying hardware architectures
   or cloud instance types.  Servers MAY apply a small amount of "noise"
   (fuzzing) to reported values to mitigate hardware-level
   identification while maintaining reporting accuracy for auditing.

4.3.  Denial of Service (DoS)

   Dynamic aggregation of metrics for custom period parameters can be
   resource-intensive.  Servers SHOULD rate-limit requests to the
   sustainability URI and cache all generated reports.

5.  IANA Considerations

   This document requests the following registration of "sustainability"
   well-known URI in the "Well-Known URIs" registry maintained at IANA
   https://www.iana.org/assignments/well-known-uris
   (https://www.iana.org/assignments/well-known-uris), following the
   procedure outlined in Section 7.1 of [RFC8615].

   *  *URI Suffix*: sustainability

   *  *Change Controller*: IETF

   *  *Specification Document*: This Document

Besleaga                Expires 16 September 2026               [Page 6]
Internet-Draft        Sustainability Well-Known URI           March 2026

   *  *Status*: Permanent

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

6.2.  Informative References

   [GHG-PROTOCOL]
              World Resources Institute and World Business Council for
              Sustainable Development, "The Greenhouse Gas Protocol: A
              Corporate Accounting and Reporting Standard (Revised
              Edition)", 2004.

   [GSF-SCI]  Green Software Foundation, "Software Carbon Intensity
              (SCI) Specification, v1.0", December 2022.

   [EU-CSRD]  European Parliament and Council, "Directive (EU) 2022/2464
              as regards corporate sustainability reporting (CSRD)",
              December 2022.

Besleaga                Expires 16 September 2026               [Page 7]
Internet-Draft        Sustainability Well-Known URI           March 2026

   [UN-SDG]   United Nations, "Transforming our world: the 2030 Agenda
              for Sustainable Development", 2015.

   [W3C-WSG]  World Wide Web Consortium, "Web Sustainability Guidelines
              (WSG) 1.0", 2023.

Author's Address

   Andrei Nicolae BESLEAGA
   Independent
   Email: andrei.besleaga@ieee.org

Besleaga                Expires 16 September 2026               [Page 8]