The 'sustainability' Well-Known URI
draft-besleaga-sustainability-wellknown-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Andrei Nicolae Besleaga | ||
| Last updated | 2026-07-08 (Latest revision 2026-07-03) | ||
| Replaces | draft-besleaga-green-sustainability-header, draft-besleaga-green-sustainability-wellknown | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| Reviews |
ARTART Early review
(of
-07)
by Tim Bray
Not ready
|
||
| Stream | ISE state | Submission Received | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-besleaga-sustainability-wellknown-02
Network Working Group A. N. Besleaga
Internet-Draft Independent
Intended status: Informational 3 July 2026
Expires: 4 January 2027
The 'sustainability' Well-Known URI
draft-besleaga-sustainability-wellknown-02
Abstract
This document defines the "sustainability" well-known URI. This URI
provides a uniform, out-of-band convention 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 4 January 2027.
Copyright Notice
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.
Besleaga Expires 4 January 2027 [Page 1]
Internet-Draft Sustainability Well-Known URI July 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 4
1.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Relationship to Other Work . . . . . . . . . . . . . . . 4
2. The "sustainability" Well-Known URI . . . . . . . . . . . . . 5
2.1. URI Definition . . . . . . . . . . . . . . . . . . . . . 5
2.2. Mandatory Minimum Supported Service . . . . . . . . . . . 5
2.3. Optional Extended Query Parameters . . . . . . . . . . . 6
2.4. Payload Format (JSON Data Model) . . . . . . . . . . . . 7
2.4.1. Mandatory Response Fields . . . . . . . . . . . . . . 7
2.4.2. Optional Response Fields . . . . . . . . . . . . . . 9
2.4.3. Versioning and Extensibility . . . . . . . . . . . . 11
2.4.4. Formal Definition (CDDL) . . . . . . . . . . . . . . 11
2.4.5. Formal Definition (JTD) . . . . . . . . . . . . . . . 13
3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Basic Response (Root Request) . . . . . . . . . . . . . . 13
3.2. Yearly Trend (Monthly Granularity) . . . . . . . . . . . 14
3.3. Target-Specific Request (Day Period) . . . . . . . . . . 15
3.4. Target-Specific Yearly Trend (Monthly Granularity) . . . 16
3.5. Highly Detailed Combined Extended Request . . . . . . . . 17
3.6. Unreported Metric (Not-Reported Sentinel) . . . . . . . . 18
4. Operational Considerations . . . . . . . . . . . . . . . . . 19
4.1. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Interoperability . . . . . . . . . . . . . . . . . . . . . . 19
6. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 20
7.2. Array Size Limits . . . . . . . . . . . . . . . . . . . . 20
7.3. Trust and Spoofing . . . . . . . . . . . . . . . . . . . 21
7.4. Greenwashing and Misrepresentation . . . . . . . . . . . 21
7.5. Privacy and Information Leakage . . . . . . . . . . . . . 21
7.6. Integrity and Transport Security . . . . . . . . . . . . 21
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 22
8.2. Hardware Fingerprinting . . . . . . . . . . . . . . . . . 22
8.3. Path Disclosure . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 26
A.1. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 26
A.2. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 28
Besleaga Expires 4 January 2027 [Page 2]
Internet-Draft Sustainability Well-Known URI July 2026
A.3. draft-besleaga-sustainability-wellknown-00 (replaces
draft-besleaga-green-sustainability-wellknown) . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
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], as
well as 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.
These transparency efforts align with the United Nations 2030 Agenda
for Sustainable Development [UN-SDG], specifically supporting energy
efficiency and sustainable infrastructure targets, encouraging
companies to integrate sustainability information into their
reporting cycles. The need for better data on the environmental
impact of Internet systems, and the current gaps in that data, are
documented in the report of the IAB Workshop on Environmental Impact
of Internet Applications and Systems [RFC9547].
While initial proposals for carbon transparency focused on per-
request HTTP headers, such methods introduce a "rebound effect" where
metadata increases the carbon footprint of the transaction. This
document leverages [RFC8615] to define a /.well-known/sustainability
URI for out-of-band reporting. This out-of-band mechanism allows
servers to publish periodic, aggregated metrics, enabling workflows
where environmental impact is a primary constraint alongside cost and
performance.
This document continues and replaces draft-besleaga-green-
sustainability-wellknown. The rename reflects that this is an
individual Independent Submission and is not scoped to any IETF
Working Group. The field set and wire format are unchanged from that
document; schema version 1.1 (which introduced the optional
disclosure-uri field) is used as the default, and this revision adds
only clarifications, which are summarized in the Changelog.
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.
Besleaga Expires 4 January 2027 [Page 3]
Internet-Draft Sustainability Well-Known URI July 2026
1.2. Goals and Non-Goals
1.2.1. Goals
* Provide a single, discoverable location for environmental metrics
for an origin.
* Define a minimal, machine-readable JSON structure, suitable for
broad adoption.
* Ensure interoperability between clients and servers.
* Support alignment with GHG Protocol, EU CSRD, and Digital Product
Passports.
* Mitigate security and privacy risks associated with publishing the
data (like hardware fingerprinting).
1.2.2. Non-Goals
* This document does not mandate a specific calculation or
measurement methodology.
* It does not define the verification, validation, certificates, or
attestation mechanisms for the data itself, though it provides
links to external attestations.
* It does not replace domain-specific reporting standards; it
defines discovery and semantics and provides a discovery surface
for linking to authoritative reports.
1.3. Relationship to Other Work
This document specifies an application-layer discovery mechanism for
aggregated, origin-level environmental metrics. It defines discovery
and data semantics only, over HTTP [RFC9110], and does not profile or
constrain the underlying measurement methodology.
In particular, it does not define, profile, or update network-
equipment energy metrics, YANG data models, or network-domain energy
monitoring and capability discovery. Such work is the subject of the
IETF GREEN Working Group and, earlier, of the EMAN framework
[RFC7326]; the GREEN charter explicitly excludes carbon accounting
and reporting. This document therefore does not overlap with,
update, or obsolete any IETF-stream document, and is complementary to
that network-layer work. Sustainability at the level of the Internet
as a whole is also a topic of research in the IRTF (for example, the
Sustainability and the Internet Research Group), which defers
Besleaga Expires 4 January 2027 [Page 4]
Internet-Draft Sustainability Well-Known URI July 2026
protocol standardization to the IETF; this document is an individual
Independent Submission and is not a product of, nor endorsed by, any
IETF Working Group or IRTF Research Group.
This document complements existing disclosure conventions rather than
replacing them. In particular, the Green Web Foundation carbon.txt
convention [CARBON-TXT] is a TOML index that links an origin to its
published sustainability disclosures (reports, certificates, and
hosting or energy-source evidence); it records _where_ an origin's
disclosures live. The "sustainability" well-known URI instead
publishes the _numeric metrics themselves_ in JSON. The two compose:
a Sustainability Metadata Document MAY link to a carbon.txt file
through the optional disclosure-uri field, and a carbon.txt file MAY
list the /.well-known/sustainability endpoint among an origin's
disclosures.
2. The "sustainability" Well-Known URI
2.1. URI Definition
This document defines the "sustainability" well-known URI and
requests its registration in the "Well-Known URIs" registry (see the
IANA Considerations section). A client requests metrics by issuing
an HTTP GET (or HEAD) request. When published, the metadata MUST be
located at the path /.well-known/sustainability on the origin.
* *Origin*: The combination of scheme, host, and optional port
(e.g., https://example.com).
* *Sustainability Metadata Document*: The JSON document returned
from /.well-known/sustainability.
* *Provider*: The entity operating the origin and publishing the
sustainability metadata.
2.2. Mandatory Minimum Supported Service
The resource SHOULD be served over HTTPS. The HTTP methods, status
codes, and header fields used in this document are defined in HTTP
Semantics [RFC9110]. A GET request MUST receive a 200 OK with a JSON
body when metadata is available; a HEAD request receives the same
status and headers with no message body. If no metadata is
published, servers SHOULD respond with 404 Not Found. A request
using any method other than GET or HEAD SHOULD receive 405 Method Not
Allowed with an Allow: GET, HEAD header ([RFC9110], Section 15.5.6).
Successful (200 OK) responses MUST use the application/json media
type, SHOULD follow I-JSON [RFC7493] for maximum compatibility, and
SHOULD include appropriate caching directives (see Operational
Besleaga Expires 4 January 2027 [Page 5]
Internet-Draft Sustainability Well-Known URI July 2026
Considerations). A server MAY redirect the well-known URI; clients
that follow a redirect MUST attribute the returned metrics to the
origin of the final response, and providers SHOULD NOT redirect to a
different origin.
A compliant server MUST support the following "Basic" service level:
* *No Parameters*: Requests to the root URI with no query strings.
* *Scope*: Metrics MUST represent the aggregate impact of the entire
origin.
* *Default Period*: The server MUST return the most recently
completed reporting period it publishes; a full calendar month is
RECOMMENDED.
* *Format*: The server MUST return a single JSON object.
2.3. Optional Extended Query Parameters
Servers MAY support "Extended" capabilities via the following
parameters:
* *target*: Scopes the metrics to a resource path prefix (e.g.,
?target=/api/v1/search), matched against the origin's resource
paths; the value follows URI path syntax [RFC3986] with any
reserved characters percent-encoded. Matching is byte-wise and
case-sensitive, on complete path segments. A server that scopes a
response to a requested target MUST include the target-path field
echoing the matched prefix; the absence of target-path means the
metrics are origin-wide. To avoid disclosing the existence of
unpublished paths (see Security Considerations), servers SHOULD
honor target only for a deliberately published set of path
prefixes and respond identically (per the no-data rule below) for
all other values.
* *period*: Specifies the timeframe using one of the following
calendar-date precision forms (only YYYY-MM-DD is an RFC 3339
[RFC3339] full-date):
- Year: YYYY (e.g., 2025)
- Month: YYYY-MM (e.g., 2025-01)
- Day: YYYY-MM-DD (e.g., 2026-01-01)
Calendar periods are interpreted in UTC unless the methodology
document states otherwise.
Besleaga Expires 4 January 2027 [Page 6]
Internet-Draft Sustainability Well-Known URI July 2026
* *granularity*: Defines the time "slices" within a period. This
document defines the values monthly and daily; a server SHOULD
ignore an unrecognized value or a granularity that is not finer
than the requested period. When the granularity is finer than the
period, the server SHOULD return an array of objects.
A period request without a (finer) granularity requests a single
object covering exactly that period. If the server holds only finer-
grained data for the requested period, it SHOULD either aggregate it
into a single object (summing energy and carbon after conversion to a
single declared unit) or respond per the no-data rule below; it MUST
NOT return an array unless a granularity finer than the period was
requested. For a requested period that has not yet completed, the
server SHOULD report the completed portion to date.
Servers that do not support the Extended parameters MUST ignore any
such parameters and return the Basic response, rather than failing
the request. If a supported parameter carries a malformed value (for
example, a period that is not a valid date), the server MAY respond
with 400 Bad Request, or ignore the offending parameter and process
the remainder of the request. When a server supports the requested
parameters but has no data for a valid requested period or target, it
SHOULD respond with 404 Not Found.
2.4. Payload Format (JSON Data Model)
A successful response MUST return, with the media type application/
json, either a single JSON object [RFC8259] or an array of such
objects (an array is used to convey a trend, that is, several
reporting periods). A single object is equivalent to a one-element
array; clients MUST accept both forms and determine which was
returned from the JSON top-level type.
In an array response, the entries MUST be sorted in ascending order
of reporting-period, MUST NOT cover overlapping periods, and MUST
share the same period precision and (where present) the same target-
path; the same units SHOULD be used across all entries.
2.4.1. Mandatory Response Fields
* *version* (string): An informational label identifying the schema
revision the publisher used to build this document (e.g., "1.1").
It is a human- and debugging-oriented hint only and carries no
negotiation or conformance semantics. Clients MUST NOT reject a
document, or alter processing, solely because of the value of this
field, and MUST apply the "ignore unknown fields" rule (see
Versioning and Extensibility) regardless of the value present.
Besleaga Expires 4 January 2027 [Page 7]
Internet-Draft Sustainability Well-Known URI July 2026
* *updated* (string, date-time): The timestamp (RFC 3339) when the
document was last updated.
* *capabilities* (string): A self-declared indicator of the service
level reflected by this document. It MUST be either "basic" or
"extended". "basic" denotes the minimal service, in which the
response is expected to carry only the mandatory fields.
"extended" denotes that extended capabilities apply, meaning that
the Extended query parameters are supported and/or one or more
optional fields are present. The value is determined per response
and MAY, at the provider's discretion, reflect the overall server,
an individual response, or a specific resource path (the target).
A value of "extended" does not, by itself, guarantee support for
any particular Extended parameter or optional field; clients
determine actual support from the fields present and from the
server's behavior. A response declaring basic SHOULD NOT include
optional fields; if it nevertheless does, clients MUST process the
document normally; the fields present take precedence over the
label.
* *provider* (string): Information about the provider publishing the
metadata.
* *measurement-method* (string): Short description or reference to
the methodology used. This is a free-form string; the values
hardware-metered, hardware-estimated, cloud-billing, and third-
party-modeled are RECOMMENDED.
* *methodology-uri* (string): Link to the full methodology
specification (calculation methodology).
* *reporting-period* (string): The timeframe covered by the object,
expressed using the same [RFC3339] date formats as the period
parameter (YYYY, YYYY-MM, or YYYY-MM-DD).
* *energy-consumption* (numeric): A numerical value indicating the
total energy consumed by the origin or resource during the
reporting period.
* *energy-unit* (string): A string indicating the unit of energy
(MUST be one of: Wh, kWh, MWh, or GWh).
* *carbon-footprint* (numeric): Total impact in grams of CO2
equivalent.
* *carbon-unit* (string): A string indicating the unit of carbon
measurement (MUST be one of: gCO2e, kgCO2e, or mtCO2e).
Besleaga Expires 4 January 2027 [Page 8]
Internet-Draft Sustainability Well-Known URI July 2026
2.4.1.1. Unreported Numeric Metrics
All required members MUST be present so that the document is schema-
valid. However, a required numeric metric is not always available
for a given scope or period. To distinguish "not reported" from a
genuine zero measurement, a negative value (for example, -1) in a
required numeric field (namely energy-consumption or carbon-
footprint) MUST be interpreted as "not reported" for that field,
rather than as an actual negative measurement. The carbon-footprint
reports gross emissions and is therefore non-negative; carbon
removals, offsets, or net-negative accounting are out of scope for
this field and, where applicable, are conveyed through the linked
attestation or disclosure resources. A client encountering a
negative required metric SHOULD treat the metric as unavailable and,
where present, consult the disclosure-uri (or the methodology-uri)
for authoritative or alternative reporting. The anti-fingerprinting
noise described in the Privacy Considerations section MUST NOT be
applied to a field carrying the "not reported" sentinel.
Optional numeric fields SHOULD simply be omitted when not reported; a
negative value in an optional numeric field MUST likewise be
interpreted as "not reported" (omission remains RECOMMENDED).
Consumers that require a value not present (or marked unreported) in
this document SHOULD look to the linked disclosure or reporting
resources.
Publishing a document in which both energy-consumption and carbon-
footprint are unreported is NOT RECOMMENDED unless the document
includes a disclosure-uri or verifiable-attestation-uri pointing to
where the metrics can be found; a document carrying neither
measurements nor such a link conveys no information.
2.4.2. Optional Response Fields
The JSON object MAY contain the following OPTIONAL keys to align with
the [GHG-PROTOCOL], European Sustainability Reporting Standards (ESRS
E1), other sustainability recommendations, and optional extended
capabilities (a capabilities value of extended does not require every
optional field to appear):
* *target-path* (string): The resource path requested as target.
* *carbon-accounting* (string): "location-based" or "market-based"
(following [GHG-PROTOCOL]).
* *scope-1* (numeric): Estimated Scope 1 (direct) carbon emissions.
Besleaga Expires 4 January 2027 [Page 9]
Internet-Draft Sustainability Well-Known URI July 2026
* *scope-2* (numeric): Estimated Scope 2 (indirect/purchased energy)
carbon emissions.
* *scope-3* (numeric): Estimated Scope 3 (value chain) carbon
emissions.
* *sci-score* (numeric): Software Carbon Intensity (SCI) score
[GSF-SCI]. If sci-score is present, functional-unit MUST also be
present.
* *functional-unit* (string): The functional unit to which per-unit
metrics are expressed (e.g., "per-request", "per-user"); its
precise meaning SHOULD be defined in the methodology-uri document.
* *carbon-intensity-gCO2-per-kWh* (numeric): Weighted carbon
intensity in grams CO2 per kWh.
* *estimated-annual-emissions-kgCO2* (numeric): Estimated annual
emissions attributable to the origin.
* *renewable-energy* (numeric): Percentage (0-100) of energy from
sustainable renewable sources.
* *verifiable-attestation-uri* (string): Link pointing to a
verifiable credential or attestation, to support independent
verification of the published metrics.
* *disclosure-uri* (string): URI of a machine-readable
sustainability disclosure index for the origin, that is, a single
document listing links to the origin's public sustainability
disclosures (reports, certificates, hosting and energy-source
evidence). The field is format-agnostic; the canonical example is
a Green Web Foundation carbon.txt file [CARBON-TXT], which is
itself commonly published at /carbon.txt or /.well-known/
carbon.txt. A disclosure-uri links to supporting evidence and
MUST NOT be treated by clients as proof of the metrics in this
document.
The scope-1, scope-2, and scope-3 values are expressed in the unit
given by carbon-unit; sci-score is expressed in grams of CO2e per the
declared functional-unit.
Fields not defined in this specification MAY be present; clients MUST
ignore any members they do not recognize.
Besleaga Expires 4 January 2027 [Page 10]
Internet-Draft Sustainability Well-Known URI July 2026
2.4.3. Versioning and Extensibility
This document is designed so that new fields can be introduced over
time without breaking deployed clients and without requiring a
revision of this specification.
* Forward compatibility rests on a single rule: clients MUST ignore
members they do not recognize. Because no field defined here is
security-critical, silently ignoring an unknown member is safe.
The formal schemas (CDDL and JTD) are correspondingly open and
permit additional members.
* Interoperability does not depend on the version member. As stated
in its definition, version is an informational label; clients MUST
NOT reject a document, or change their processing, because of an
unrecognized version value.
* New fields may be introduced by a future specification, or
privately by an implementer. To avoid collisions, vendor or
private members SHOULD be namespaced, for example with a vendor-
prefix, a domain-qualified name, or a URI key. Implementers
introducing a field of general interest are encouraged to publish
its definition so that others can interoperate.
* The values "1.0" and "1.1" denote historical schema revisions; 1.1
added the optional disclosure-uri field. Documents declaring
either value remain valid, and introducing further fields does
not, by itself, require a new version value.
2.4.4. Formal Definition (CDDL)
The following CDDL [RFC8610] describes the response:
Besleaga Expires 4 January 2027 [Page 11]
Internet-Draft Sustainability Well-Known URI July 2026
; Root: a single object, or an array of objects for trends
sustainability-response =
sustainability-metrics / [* sustainability-metrics]
sustainability-metrics = {
; Versioning and provenance
version: tstr,
updated: tstr,
provider: tstr,
capabilities: "basic" / "extended",
; Mandatory methodology disclosure
measurement-method: tstr,
methodology-uri: tstr,
; Timeframe of the report (RFC3339 formatted string)
reporting-period: tstr,
; Energy units are fixed literals to ensure interoperability
; A negative required metric (e.g. -1) means "not reported"
energy-consumption: number,
energy-unit: "Wh" / "kWh" / "MWh" / "GWh",
; Carbon metrics (negative value = not reported)
carbon-footprint: number,
carbon-unit: "gCO2e" / "kgCO2e" / "mtCO2e",
; Optional fields for extended capabilities
? carbon-accounting: "location-based" / "market-based",
? target-path: tstr,
? scope-1: number,
? scope-2: number,
? scope-3: number,
? sci-score: number,
? functional-unit: tstr,
? carbon-intensity-gCO2-per-kWh: number,
? estimated-annual-emissions-kgCO2: number,
? renewable-energy: number, ; percentage, 0-100
? verifiable-attestation-uri: tstr,
? disclosure-uri: tstr,
; Vendor extensions; clients MUST ignore unknown members
* tstr => any
}
Besleaga Expires 4 January 2027 [Page 12]
Internet-Draft Sustainability Well-Known URI July 2026
2.4.5. Formal Definition (JTD)
The following JSON Type Definition [RFC8927] defines the reporting
object:
{
"properties": {
"version": { "type": "string" },
"updated": { "type": "string" },
"capabilities": { "enum": ["basic", "extended"] },
"provider": { "type": "string" },
"measurement-method": { "type": "string" },
"methodology-uri": { "type": "string" },
"reporting-period": { "type": "string" },
"energy-consumption": { "type": "float64" },
"energy-unit": { "enum": ["Wh", "kWh", "MWh", "GWh"] },
"carbon-footprint": { "type": "float64" },
"carbon-unit": { "enum": ["gCO2e", "kgCO2e", "mtCO2e"] }
},
"optionalProperties": {
"target-path": { "type": "string" },
"carbon-accounting": {
"enum": ["location-based", "market-based"]
},
"scope-1": { "type": "float64" },
"scope-2": { "type": "float64" },
"scope-3": { "type": "float64" },
"sci-score": { "type": "float64" },
"functional-unit": { "type": "string" },
"carbon-intensity-gCO2-per-kWh": { "type": "float64" },
"estimated-annual-emissions-kgCO2": { "type": "float64" },
"renewable-energy": { "type": "float64" },
"verifiable-attestation-uri": { "type": "string" },
"disclosure-uri": { "type": "string" }
},
"additionalProperties": true
}
3. Example Usage
3.1. Basic Response (Root Request)
Request: GET /.well-known/sustainability
Besleaga Expires 4 January 2027 [Page 13]
Internet-Draft Sustainability Well-Known URI July 2026
{
"version": "1.1",
"updated": "2026-03-01T12:00:00Z",
"capabilities": "basic",
"provider": "Example Corp (sustain@example.org)",
"measurement-method": "cloud-billing",
"methodology-uri": "https://example.com/sustainability",
"reporting-period": "2026-02",
"energy-consumption": 1250,
"energy-unit": "kWh",
"carbon-footprint": 345000,
"carbon-unit": "gCO2e"
}
3.2. Yearly Trend (Monthly Granularity)
Request: GET /.well-known/
sustainability?period=2025&granularity=monthly
The response is an array with one object per month; only the first
two months are shown here for brevity.
Besleaga Expires 4 January 2027 [Page 14]
Internet-Draft Sustainability Well-Known URI July 2026
[
{
"version": "1.1",
"updated": "2026-01-05T09:00:00Z",
"capabilities": "extended",
"provider": "CloudProvider Ops (ops@example.com)",
"measurement-method": "hardware-metered",
"methodology-uri": "https://example.com/methodology",
"reporting-period": "2025-01",
"energy-consumption": 1100,
"energy-unit": "kWh",
"carbon-footprint": 302,
"carbon-unit": "kgCO2e",
"carbon-accounting": "location-based",
"renewable-energy": 45
},
{
"version": "1.1",
"updated": "2026-01-05T09:00:00Z",
"capabilities": "extended",
"provider": "CloudProvider Ops (ops@example.com)",
"measurement-method": "hardware-metered",
"methodology-uri": "https://example.com/methodology",
"reporting-period": "2025-02",
"energy-consumption": 1050,
"energy-unit": "kWh",
"carbon-footprint": 288,
"carbon-unit": "kgCO2e",
"carbon-accounting": "location-based",
"renewable-energy": 48
}
]
3.3. Target-Specific Request (Day Period)
Request: GET /.well-known/sustainability?target=/api/
v1&period=2026-03-15
Besleaga Expires 4 January 2027 [Page 15]
Internet-Draft Sustainability Well-Known URI July 2026
{
"version": "1.1",
"updated": "2026-03-16T12:00:00Z",
"capabilities": "extended",
"target-path": "/api/v1",
"reporting-period": "2026-03-15",
"provider": "Example Corp (sustain@example.org)",
"measurement-method": "cloud-billing",
"methodology-uri": "https://example.com/sustainability",
"energy-consumption": 40,
"energy-unit": "kWh",
"carbon-footprint": 11040,
"carbon-unit": "gCO2e"
}
3.4. Target-Specific Yearly Trend (Monthly Granularity)
Request: GET /.well-known/sustainability?target=/api/
v1&period=2026&granularity=monthly
As above, the array holds one object per month; only the first two
are shown for brevity.
Besleaga Expires 4 January 2027 [Page 16]
Internet-Draft Sustainability Well-Known URI July 2026
[
{
"version": "1.1",
"updated": "2026-03-21T07:00:00Z",
"capabilities": "extended",
"target-path": "/api/v1",
"provider": "Example Corp (sustain@example.org)",
"measurement-method": "third-party-modeled",
"methodology-uri": "https://example.com/api-modeling",
"reporting-period": "2026-01",
"energy-consumption": 45,
"energy-unit": "kWh",
"carbon-footprint": 12450,
"carbon-unit": "gCO2e",
"sci-score": 12,
"functional-unit": "per-thousand-requests"
},
{
"version": "1.1",
"updated": "2026-03-21T07:00:00Z",
"capabilities": "extended",
"target-path": "/api/v1",
"provider": "Example Corp (sustain@example.org)",
"measurement-method": "third-party-modeled",
"methodology-uri": "https://example.com/api-modeling",
"reporting-period": "2026-02",
"energy-consumption": 42,
"energy-unit": "kWh",
"carbon-footprint": 11800,
"carbon-unit": "gCO2e",
"sci-score": 10,
"functional-unit": "per-thousand-requests"
}
]
3.5. Highly Detailed Combined Extended Request
Request: GET /.well-known/sustainability?target=/app/
storage&period=2026-03-20
This example utilizes almost all optional fields, including GHG
Protocol Scopes and a verifiable attestation link to combat
greenwashing.
Besleaga Expires 4 January 2027 [Page 17]
Internet-Draft Sustainability Well-Known URI July 2026
{
"version": "1.1",
"updated": "2026-03-21T00:05:00Z",
"capabilities": "extended",
"provider": "Global Storage Inc. (compliance@storage.example)",
"measurement-method": "hardware-estimated",
"methodology-uri": "https://storage.example/transparency/methods",
"reporting-period": "2026-03-20",
"target-path": "/app/storage",
"energy-consumption": 12,
"energy-unit": "kWh",
"carbon-footprint": 3.2,
"carbon-unit": "kgCO2e",
"carbon-accounting": "market-based",
"scope-1": 0.0,
"scope-2": 2.1,
"scope-3": 1.1,
"sci-score": 0.85,
"functional-unit": "per-terabyte-day",
"carbon-intensity-gCO2-per-kWh": 267,
"estimated-annual-emissions-kgCO2": 1168,
"renewable-energy": 45,
"verifiable-attestation-uri": "https://verify.example/vc/storage",
"disclosure-uri": "https://storage.example/.well-known/carbon.txt"
}
3.6. Unreported Metric (Not-Reported Sentinel)
Request: GET /.well-known/sustainability
In this example the provider has a carbon figure (for example, from a
supplier or a CSRD report) but does not report energy. The required
energy-consumption field is therefore set to the negative "not
reported" sentinel (see "Unreported Numeric Metrics"), and the
disclosure-uri points to where the missing data can be found.
Besleaga Expires 4 January 2027 [Page 18]
Internet-Draft Sustainability Well-Known URI July 2026
{
"version": "1.1",
"updated": "2026-04-01T00:00:00Z",
"capabilities": "extended",
"provider": "Partial Metrics Co. (sustainability@partial.example)",
"measurement-method": "third-party-modeled",
"methodology-uri": "https://partial.example/methodology",
"reporting-period": "2026-03",
"energy-consumption": -1,
"energy-unit": "kWh",
"carbon-footprint": 4200,
"carbon-unit": "gCO2e",
"carbon-accounting": "location-based",
"scope-2": 4200,
"disclosure-uri": "https://partial.example/.well-known/carbon.txt"
}
4. Operational Considerations
4.1. Caching
Because this endpoint can be dynamic, servers SHOULD implement heavy
caching for the well-known responses (see also the rate-limiting
guidance in the Security Considerations). HTTP caching and
conditional requests are as defined in [RFC9111] and [RFC9110].
* Servers SHOULD set cache directives (e.g., Cache-Control: max-
age=86400) [RFC9111].
* For historical reports, a long max-age (e.g., one year) is
RECOMMENDED.
* Use of ETag and Last-Modified ([RFC9110], Sections 8.8.3 and
8.8.2), enabling conditional requests with If-None-Match, is
RECOMMENDED.
5. Interoperability
To maximize interoperability:
* Servers SHOULD keep their published documents current with this
specification.
* Clients MUST tolerate unknown fields and future versions.
* Implementers SHOULD publish example payloads and test vectors.
Besleaga Expires 4 January 2027 [Page 19]
Internet-Draft Sustainability Well-Known URI July 2026
* Aggregators SHOULD document how they map provider fields to their
internal models.
6. Deployment
* For multi-tenant platforms, operators SHOULD decide whether to
publish per-tenant metadata at the tenant origin or a platform-
level summary.
* Operators deploying behind CDNs or reverse proxies MUST ensure
that the /.well-known/sustainability path is routed to the
authoritative publisher or proxied correctly.
* Automation: Providers SHOULD automate updates to the document to
reflect changes in energy sourcing or measurement.
7. Security Considerations
7.1. Denial of Service (DoS)
Because this endpoint may require internal database queries to
aggregate data - especially when dynamic period or other query
parameters are utilized - it could become a vector for Denial of
Service (DoS) attacks. 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.
* Because each distinct query-string combination is a distinct cache
entry, an attacker iterating unique parameter values can bypass a
response cache; honoring target only for a published set of path
prefixes (see Optional Extended Query Parameters) bounds the key
space, and servers SHOULD precompute reports rather than aggregate
on demand.
7.2. Array Size Limits
To prevent Denial of Service (DoS) via memory exhaustion, servers
supporting granularity MUST limit the maximum number of objects
returned.
* A cap of 366 objects is RECOMMENDED.
* When a response would exceed the limit, the server SHOULD return
the most recent periods and MAY signal the truncation (for
example, via an extension member), or MAY respond with 400 Bad
Request.
Besleaga Expires 4 January 2027 [Page 20]
Internet-Draft Sustainability Well-Known URI July 2026
7.3. Trust and Spoofing
Publishing sustainability metadata at a well-known location is
convenient but does not provide any cryptographic assurance of
correctness. An attacker who controls DNS, TLS certificates, or the
origin can publish false metadata.
* Clients MUST NOT treat the presence of a sustainability document
as proof of any claim.
* For high-assurance use cases, clients SHOULD rely on additional
attestations, signed statements, or third-party verification.
7.4. Greenwashing and Misrepresentation
There is a risk that providers publish misleading or incomplete
metrics to appear more sustainable.
* Providers SHOULD include links to measurement methodologies,
authoritative reports, signed statements, additional attestations,
or third-party verification.
* Consumers SHOULD treat the document as a discovery mechanism and
validate claims against external sources when necessary.
* Providers SHOULD include links to cryptographically signed W3C
Verifiable Credentials in the verifiable-attestation-uri field to
combat greenwashing.
7.5. Privacy and Information Leakage
Publishing detailed operational metrics may reveal sensitive
information about infrastructure, traffic patterns, or deployment
topology.
* Providers SHOULD avoid publishing data that could be used to infer
internal architecture or expose personally identifiable
information.
* Aggregators SHOULD use privacy-preserving aggregation techniques
when publishing derived datasets.
7.6. Integrity and Transport Security
* The resource SHOULD be served over HTTPS to protect integrity and
privacy.
Besleaga Expires 4 January 2027 [Page 21]
Internet-Draft Sustainability Well-Known URI July 2026
* Clients MUST validate TLS certificates according to standard
practice.
8. Privacy Considerations
Publishing sustainability metadata can have privacy implications when
metrics are correlated with traffic or user behavior. Providers
SHOULD evaluate the privacy impact of any metric that could be linked
to individual users or small groups. When in doubt, aggregate or
redact fine-grained data.
8.1. Traffic Analysis
Servers SHOULD NOT report metrics at a granularity finer than 24
hours to prevent correlating energy spikes with specific real-time
user actions. Real-time telemetry is NOT RECOMMENDED as it could
allow an attacker to correlate energy usage with real-time actions.
8.2. Hardware Fingerprinting
Precise metrics can reveal hardware architectures. Servers MAY apply
"noise" (fuzzing), uniformly bounded within approximately 1% of the
true values, to mitigate identification with limited impact on
aggregate accuracy. Noise MUST be applied once, at document-
generation time, deterministically per reporting period, and
consistently across arithmetically related fields (so that, for
example, scope values still sum to the reported carbon-footprint);
the noised values are the published values for caching and
conditional-request purposes. Providers applying noise SHOULD
disclose this in the methodology-uri document so that auditors can
reconcile published figures with filed reports.
8.3. Path Disclosure
When target is honored for arbitrary values, the difference between a
scoped response and a no-data response can reveal which resource
paths exist and carry traffic on the origin. As specified in
Optional Extended Query Parameters, servers SHOULD honor target only
for a deliberately published set of path prefixes and respond
identically for all other values.
9. IANA Considerations
IANA is requested to register the "sustainability" well-known URI in
the "Well-Known URIs" registry (https://www.iana.org/assignments/
well-known-uris), following the procedure outlined in [RFC8615].
This registration enables interoperable discovery of sustainability
metadata.
Besleaga Expires 4 January 2027 [Page 22]
Internet-Draft Sustainability Well-Known URI July 2026
Following the registration template of [RFC8615], Section 3.1:
* *URI Suffix*: sustainability
* *Change Controller*: Andrei Nicolae Besleaga
(andrei.besleaga@ieee.org)
* *Specification Document(s)*: This document.
* *Status*: provisional
* *Related Information*: This suffix is used with the "http" and
"https" URI schemes. The response uses the application/json media
type [RFC8259] and SHOULD follow I-JSON [RFC7493]. Formal
definitions of the response are provided in this document using
CDDL [RFC8610] and JSON Type Definition (JTD) [RFC8927].
A status of "provisional" is requested in keeping with [RFC8615],
Section 3.1: this is an Independent Submission rather than a
Standards-Track or other open-standards-process document. Per that
procedure, the designated expert(s) may promote the entry to
"permanent" once it is found to be in broad use.
The single-token suffix "sustainability" is intentionally chosen: the
metadata it names is site-wide (origin-level) rather than tied to a
particular resource, which is the pattern for which well-known URIs
are appropriate [RFC8615]. Resource-specific scoping is provided
through the target query parameter rather than through additional
path segments. The use of query parameters on a well-known URI
follows existing practice such as WebFinger [RFC7033] and is
permitted by [RFC8615], Section 3. Registration is sought to enable
interoperable discovery, not to signal endorsement of the publisher's
claims.
10. Acknowledgments
Thanks to the early reviewers and to members of the Internet
sustainability community who provided feedback on sustainability
metadata and discovery patterns.
11. References
11.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>.
Besleaga Expires 4 January 2027 [Page 23]
Internet-Draft Sustainability Well-Known URI July 2026
[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>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
[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>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8927] Carion, U., "JSON Type Definition", RFC 8927,
DOI 10.17487/RFC8927, November 2020,
<https://www.rfc-editor.org/info/rfc8927>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
11.2. Informative References
Besleaga Expires 4 January 2027 [Page 24]
Internet-Draft Sustainability Well-Known URI July 2026
[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,
<https://ghgprotocol.org/corporate-standard>.
[GSF-SCI] Green Software Foundation, "Software Carbon Intensity
(SCI) Specification (standardized as ISO/IEC 21031:2024)",
2024, <https://sci.greensoftware.foundation/>.
[RFC9547] Arkko, J., Perkins, C. S., and S. Krishnan, "Report from
the IAB Workshop on Environmental Impact of Internet
Applications and Systems, 2022", RFC 9547,
DOI 10.17487/RFC9547, February 2024,
<https://www.rfc-editor.org/info/rfc9547>.
[EU-CSRD] European Parliament and Council, "Directive (EU) 2022/2464
as regards corporate sustainability reporting (CSRD)",
December 2022,
<https://eur-lex.europa.eu/eli/dir/2022/2464/oj>.
[UN-SDG] United Nations, "Transforming our world: the 2030 Agenda
for Sustainable Development", 2015,
<https://sdgs.un.org/2030agenda>.
[W3C-WSG] W3C Sustainable Web Design Community Group, "Web
Sustainability Guidelines (WSG) 1.0 (W3C Community Group
Report)", 2023,
<https://w3c.github.io/sustainableweb-wsg/>.
[CARBON-TXT]
Green Web Foundation, "carbon.txt: A TOML convention for
discovering an origin's sustainability disclosures", 2026,
<https://carbontxt.org/>.
[RFC7326] Parello, J., Claise, B., Schoening, B., and J. Quittek,
"Energy Management Framework", RFC 7326,
DOI 10.17487/RFC7326, September 2014,
<https://www.rfc-editor.org/info/rfc7326>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
2013, <https://www.rfc-editor.org/info/rfc7033>.
Besleaga Expires 4 January 2027 [Page 25]
Internet-Draft Sustainability Well-Known URI July 2026
Appendix A. Changelog
[Note to the RFC Editor: please remove this appendix before
publication.]
This appendix summarizes changes in recent revisions of this
document, for the convenience of reviewers. The complete revision
history, including the revisions published under the document's
former name (draft-besleaga-green-sustainability-wellknown), is
maintained in the project repository.
A.1. Since -01
This revision applies editorial and normative clarifications to
improve interoperability and readiness for Independent-stream
publication; no fields are added or removed, and all previously
published example payloads remain valid.
* Aligned the formal schemas with the "clients MUST ignore unknown
fields" rule: the CDDL map now permits vendor extensions (* tstr
=> any) and the JTD gains "additionalProperties": true, so a
conformant validator no longer rejects the extensions the text
permits.
* Corrected the date-format references: the YYYY and YYYY-MM forms
are calendar-date precision forms, not RFC 3339 productions (RFC
3339 defines the YYYY-MM-DD full-date).
* Clarified HTTP method handling (GET/HEAD; other methods -> 405
with Allow), the no-data response (404), the granularity value
set, and malformed-parameter handling.
* Specified that scope-1/2/3 are expressed in carbon-unit and sci-
score in gCO2e per functional-unit; extended the not-reported
sentinel to optional numeric fields; relaxed the Basic default
period so annual-only reporters can comply; and normativized that
a basic response omits optional fields.
* Defined target prefix-matching semantics and percent-encoding (RFC
3986, added as a normative reference).
* Added HTTP Semantics (RFC 9110) and HTTP Caching (RFC 9111) as
normative references, since the document relies on HTTP methods,
status codes (including 405/Allow), conditional requests (ETag/
Last-Modified/If-None-Match), and caching; cited them at the
relevant points.
Besleaga Expires 4 January 2027 [Page 26]
Internet-Draft Sustainability Well-Known URI July 2026
* Redefined the version member as an informational, non-negotiated
label (clients MUST NOT reject or branch on it) and rewrote
"Versioning and Extensibility" around the must-ignore rule, so
that the specification accommodates future fields without a
revision and without an in-band version-negotiation mechanism.
* Changed the requested IANA registry status from "permanent" to
"provisional" (appropriate for an Independent Submission per RFC
8615, promotable once in broad use), and added a rationale for the
single-token suffix and the query-parameter design (WebFinger
precedent).
* Sharpened the "Relationship to Other Work" section to distinguish
this application-layer, origin-level HTTP disclosure surface from
network-layer energy work (IETF GREEN, EMAN/RFC 7326) and from
IRTF research, and to state clearly that it complements, and does
not duplicate, the Green Web Foundation carbon.txt convention;
cited the IAB e-impact workshop report (RFC 9547) as motivating
context.
* Clarified that a single object is equivalent to a one-element
array and that clients MUST accept both response forms; array
entries are sorted, non-overlapping, and of uniform precision and
target.
* Interoperability hardening from pre-submission review: a period
request without finer granularity yields a single (possibly
aggregated) object; a server scoping a response to target echoes
target-path (absence means origin-wide); target matching is byte-
wise, case-sensitive, on complete path segments, against a
published set of prefixes (also closing a path-disclosure oracle
and bounding the cache key space); calendar periods are
interpreted in UTC; incomplete periods report the completed
portion; array truncation keeps the most recent periods; anti-
fingerprinting noise is applied once at generation time,
deterministically and consistently across related fields; sci-
score requires functional-unit; a document with both required
metrics unreported carries a disclosure link; redirect responses
are attributed to the final origin.
* Reference precision: identified carbon.txt as a TOML index, W3C
WSG as a Community Group Report, and SCI by its ISO/IEC 21031:2024
form.
* Corrected the arithmetic of the highly-detailed example (scopes
now sum to the reported carbon-footprint).
Besleaga Expires 4 January 2027 [Page 27]
Internet-Draft Sustainability Well-Known URI July 2026
* Revised the Acknowledgments to thank the Internet sustainability
community generally, without implying review or endorsement by any
IETF Working Group or IRTF Research Group.
* Numerous editorial fixes (typos, comma splices, heading
hyphenation, host/origin terminology, Acknowledgments spelling,
bare IANA URL). The pre-rename revision history was moved out of
this appendix to the project repository.
A.2. Since -00
Editorial/positioning update only; no change to the data model, field
semantics, service levels, or wire format, and all published example
payloads remain valid.
* Replaced "standardized, out-of-band mechanism" with "uniform, out-
of-band convention" in the Abstract, to reflect that this is an
Informational document describing a common, interoperable
convention (suited to the Independent Submission Stream and
Research Group discussion) rather than a standards-track
specification.
A.3. draft-besleaga-sustainability-wellknown-00 (replaces draft-
besleaga-green-sustainability-wellknown)
This document is an administrative continuation of draft-besleaga-
green-sustainability-wellknown, which it replaces. It makes no
change to the field set or wire format; the previously published
example payloads remain valid.
* Renamed the document from draft-besleaga-green-sustainability-
wellknown to draft-besleaga-sustainability-wellknown and recorded
a "Replaces" relationship. The prior name's "green" token could
imply a scope tied to the IETF GREEN Working Group; this is an
individual Independent Submission with no working-group
affiliation.
* Adopted schema version 1.1 as the default across all examples
(version 1.1 introduced the optional disclosure-uri field;
documents declaring 1.0 remain valid).
* Clarified the meaning of a negative value in a required numeric
field: it denotes an unreported metric (not a real negative
measurement); see "Unreported Numeric Metrics". Also noted that
carbon-footprint is gross (non-negative) and that the anti-
fingerprinting noise is not applied to the "not reported"
sentinel.
Besleaga Expires 4 January 2027 [Page 28]
Internet-Draft Sustainability Well-Known URI July 2026
* Editorial and clarity corrections for publication: the URI
Definition now states that this document _requests_ the
registration (rather than asserting it is already registered);
added a "Relationship to Other Work" note (application-layer
scope; does not update or obsolete any IETF-stream document;
complementary to carbon.txt); and specified that servers not
supporting the Extended parameters MUST ignore them and return the
Basic response.
* Data-model and example corrections: clarified the capabilities
semantics (a simple basic/extended indicator that is determined
per response and MAY reflect the server, the specific response, or
a resource path) and corrected the Target-Specific example, which
had declared basic while carrying an optional field (target-path)
and had reused the whole-host totals for a sub-path; pinned
reporting-period to the same date formats as the period parameter;
noted that measurement-method is a free-form string with
RECOMMENDED values; bounded renewable-energy to 0-100; documented
malformed-parameter handling (400 or ignore); and added a "Not-
Reported Sentinel" example.
The revision history of the replaced document, the former draft-
besleaga-green-sustainability-wellknown (its versions -00 through
-05), is not reproduced here; it is retained in the project
repository's CHANGELOG.
Author's Address
Andrei Nicolae BESLEAGA
Independent
Email: andrei.besleaga@ieee.org
Besleaga Expires 4 January 2027 [Page 29]