]> Independent

andrei.besleaga@ieee.org

Independent Submission Internet-Draft Sustainability Carbon Accounting Well-Known URI Energy Efficiency This document defines the "sustainability-data" well-known URI. This URI provides a uniform, out-of-band convention for web servers and digital services to publish aggregated environmental impact, energy consumption, and carbon footprint metrics for a declared reporting subject -- typically the publishing origin itself. 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.

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) , as well as industry standards like the Green Software Foundation's Software Carbon Intensity and the W3C Web Sustainability Guidelines , increasingly call for organizations to disclose the environmental impact of their digital services. These transparency efforts align with the United Nations 2030 Agenda for Sustainable Development , 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 . 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 to define a /.well-known/sustainability-data 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. The origin publishes the document; the document's mandatory target member declares the reporting subject -- what the metrics are about, which is typically the origin itself but may be another entity or scope (see the URI Definition section). [Note to the RFC Editor: the remainder of this paragraph records Internet-Draft lineage and may be removed or reworded at publication.] 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. Revision -03 reworked the data model: it adopted member omission as the only "not reported" mechanism, reduced the mandatory member set, introduced a mandatory target member identifying the reporting subject, and renamed two carbon members to the CO2e convention; documents built to that data model carry the informational label "2.0", and the changes are breaking with respect to the historical "1.0"/"1.1" field set (see the Changelog). As of revision -04, the requested well-known URI suffix is sustainability-data (earlier revisions requested the suffix sustainability); the change follows Independent-Stream review feedback on the precision expectations of . The convention is designed to be usable, unchanged, in four consumption contexts: by web clients, as a plain HTTPS GET on a fixed well-known URI with standard HTTP caching and conditional requests; by machine-to-machine and API integrations, as a stable JSON wire format with formal Concise Data Definition Language (CDDL) and JSON Type Definition (JTD) schemas and well-defined query and response semantics; by human readers, through self-describing member names and a mandatory link to the measurement methodology; and by automated agents and AI systems, as a document that is machine-discoverable at a fixed location, schema-validatable, and safe to ingest without content negotiation or prior arrangement.

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.

Goals and Non-Goals

Goals Provide a single, discoverable location, per origin, for environmental metrics about a declared reporting subject (typically the origin itself). Define a minimal, machine-readable JSON structure, suitable for broad adoption. Ensure interoperability between clients and servers. Support alignment with the Greenhouse Gas (GHG) Protocol , the EU CSRD and the European Sustainability Reporting Standards (ESRS) E1 climate standard , and product-level disclosure regimes such as the Digital Product Passport established by the EU Ecodesign for Sustainable Products Regulation . Mitigate security and privacy risks associated with publishing the data (like hardware fingerprinting).

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.

Relationship to Other Work This document specifies an application-layer discovery mechanism for aggregated environmental metrics published at the origin level. It defines discovery and data semantics only, over HTTP , 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 ; 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. Terminology for energy-efficient network management is being developed in that group ; this document's vocabulary is at the reporting and disclosure layer and does not redefine those network-management terms. 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 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 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, and contains no quantitative metrics. The "sustainability-data" well-known URI instead publishes the numeric metrics themselves in JSON. The two compose without either depending on the other: a Sustainability Metadata Document (defined in the URI Definition section) can link to a disclosure index -- a carbon.txt file being one such form among others -- through the optional disclosure-uri member, and a carbon.txt file can list the /.well-known/sustainability-data endpoint among an origin's disclosures.

The "sustainability-data" Well-Known URI

URI Definition This document defines the "sustainability-data" 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. A provider publishing the metadata MUST make it available at the path /.well-known/sustainability-data on the origin. Origin: The combination of scheme, host, and optional port (e.g., https://example.com); see also the web origin concept . Sustainability Metadata Document: The JSON document returned from /.well-known/sustainability-data. Provider: The entity operating the origin and publishing the sustainability metadata (also referred to as the publisher). Reporting subject: The entity or scope that a Sustainability Metadata Document's metrics describe, identified by the mandatory target member of each object. The origin is where the document is published; the reporting subject is what the data is about -- most commonly the origin itself (see the target member in Mandatory Response Fields for the range of possible subjects).

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 . Absent redirection, cache revalidation, or rate limiting, a GET request MUST receive a 200 OK with a JSON body when metadata is available; a HEAD request MUST receive the same status and header fields 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 (, Section 15.5.6). Successful (200 OK) responses MUST use the application/json media type, SHOULD follow I-JSON for maximum compatibility, and SHOULD include appropriate caching directives (see Operational Considerations). Because the document is public and intended for browser-based clients as well, successful responses SHOULD also include an Access-Control-Allow-Origin: * header (Cross-Origin Resource Sharing), following the practice of WebFinger . A server MAY redirect the well-known URI; clients that follow a redirect MUST attribute the returned document 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: The response to a parameterless request MUST cover the provider's full declared reporting subject, identified by the target member (see Mandatory Response Fields). When the reporting subject is the origin itself -- the common case -- the metrics MUST represent the aggregate impact of the entire origin, not a subset of its resources. Default Period: The server MUST return the most recently completed reporting period it publishes. A period matching the publisher's own reporting cycle is RECOMMENDED: a full calendar year for the periodic, regulatory-style disclosure that is the common case, or a full calendar month for publishers that report more frequently. Format: The server MUST return a single JSON object.

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 with characters not permitted in a query component percent-encoded. Matching is byte-wise and case-sensitive, on complete path segments, and is performed after percent-decoding. A server that scopes a response to a requested target parameter MUST set the target member of each returned object to the matched prefix. The target query parameter and the target response member are distinct: the parameter requests path-prefix scoping, while the member identifies the reporting subject of whatever is returned (see Mandatory Response Fields). Servers SHOULD honor the target parameter only for a deliberately published set of path prefixes, responding identically (per the no-data rule below) for all other values; this avoids disclosing the existence of unpublished paths (see Privacy Considerations, Path Disclosure). period: Specifies the timeframe using one of the following calendar-date precision forms (only YYYY-MM-DD is an RFC 3339 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. These forms name a whole calendar period rather than a pair of start and end instants, which is a deliberate choice. Calendar periods -- most commonly the reporting year -- are the granularities at which the disclosure regimes this document serves already aggregate their figures, so two publishers reporting 2026 report the same nominal period, subject to the UTC default above, and their documents are directly comparable, whereas arbitrary intervals would have to be re-apportioned before any comparison. Calendar periods also keep the set of distinct parameter values small, enumerable, and canonical, which is what keeps bounded the cache-key space that Denial of Service in the Security Considerations addresses. The forms are the reduced-precision calendar dates of ISO 8601, whose use to denote a whole year or a whole month has wire precedent in vCard , Section 4.3.1; itself defines no interval type in its normative text. A publisher whose reporting year does not align with the calendar year can publish the constituent months, or the enclosing calendar years, and describe the alignment in the methodology-uri document; an explicit interval form could be introduced later as an extension under Versioning and Extensibility without invalidating any document published under this specification. 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; a granularity without a period applies to the default period of the Basic service. If the server holds only finer-grained data for the requested period, it SHOULD either aggregate it into a single object or respond per the no-data rule below. Aggregation sums energy and carbon after conversion to a single declared unit; other metrics SHOULD be recomputed for the aggregated period or omitted. The server 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. (This applies to syntactically invalid values; an unrecognized value of an enumerated parameter such as granularity is instead ignored, as specified above.) When a server supports the requested parameters but has no data for a valid requested period or target parameter value, it SHOULD respond with 404 Not Found (the "no-data rule").

Payload Format (JSON Data Model) A successful response body MUST be either a single JSON object or an array of such objects (an array is used to convey a trend, that is, several reporting periods); the media type is application/json, as required in Mandatory Minimum Supported Service. 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. An array response MUST contain at least one object (a server with nothing to report follows the no-data rule instead); a client that nevertheless receives an empty array SHOULD treat it as conveying no report. 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 the same target value; target-type MUST be either present in every entry with the same value or absent from every entry. The same units SHOULD be used across all entries; other members (for example, capabilities or provider) are not constrained across entries.

Mandatory Response Fields version (string): An informational label identifying the schema revision the publisher used to build this document (e.g., "2.0"). 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 apply the ignore-unknown rule (see Versioning and Extensibility) regardless of the value present. updated (string, date-time): The timestamp () when the document was last updated. capabilities (string): A self-declared indicator of the service level. It MUST be either "basic" or "extended". "basic" denotes that only the Mandatory Minimum Supported Service is provided; "extended" denotes that one or more of the Optional Extended Query Parameters are supported. The value describes query-parameter support, not member presence: a document declaring "basic" MAY carry any optional members. The value is determined per response and MAY, at the provider's discretion, reflect the overall server, an individual response, or a specific reporting subject (the target member). A value of "extended" does not, by itself, guarantee support for any particular Extended parameter; clients determine actual support from the server's behavior. provider (string): Information about the provider publishing the metadata. measurement-method (string): The methodology used, given as a short token or reference. The values hardware-metered, hardware-estimated, cloud-billing, and third-party-modeled are RECOMMENDED and are machine-matchable tokens compared as described in the Internationalization Considerations section; a publisher whose method is not one of these gives a brief description instead, which is human-readable text. methodology-uri (string): Link to the full methodology specification (calculation methodology). In general, the methodology document SHOULD describe the measurement or estimation method in enough detail to interpret the published figures, and is the designated place for details that other provisions of this document direct there -- among them: any non-UTC interpretation of calendar periods, the precise meaning of a functional-unit, the extrapolation behind estimated-annual-emissions-kgCO2e, the net-accounting basis of any negative scope values, and any anti-fingerprinting noise applied (see Privacy Considerations). See also the minimum-reporting rule in Value Constraints and Omitted Metrics. reporting-period (string): The timeframe covered by the object, expressed using the same calendar-date forms as the period parameter (YYYY, YYYY-MM, or the full-date YYYY-MM-DD); those forms, and the reasons this document names whole calendar periods rather than arbitrary intervals, are given in Optional Extended Query Parameters. target (string): The reporting subject of this object: an identifier of the entity or scope to which the metrics are attributed. It is an opaque protocol element, not display text: clients compare it octet-for-octet and MUST NOT translate or transliterate it (see Internationalization Considerations, which gives the comparison rules for a target that names a host or a path prefix). Typical values are an origin or domain (for an origin-wide report the origin's host, e.g., "example.com", is RECOMMENDED), a resource path prefix (e.g., "/api/v1"), an organizational entity, a cloud tenant or provider scope, a software product or data source (e.g., "example-metrics-feed"), or a device. When the response is scoped by the target query parameter, the member carries the matched prefix, as required in Optional Extended Query Parameters -- which also distinguishes the parameter from this member. The reporting subject SHOULD be within the provider's own operational responsibility; clients SHOULD treat a target naming a subject other than the origin as a claim made by the origin's operator about that subject, and nothing more (see Trust and Spoofing). The OPTIONAL target-type member (see Optional Response Fields) can classify the kind of subject named here.

Optional Response Fields The JSON object MAY contain the following OPTIONAL keys to align with the GHG Protocol , the ESRS E1 climate standard , and other sustainability recommendations: energy-consumption (numeric): Total energy consumed by the reporting subject during the reporting period. The value MUST NOT be negative. It is expressed in the unit given by energy-unit (default kWh; see that member). energy-unit (string): The unit of energy for energy-consumption (MUST be one of: Wh, kWh, MWh, or GWh). When this member is absent, the default kWh applies. Publishers SHOULD state the unit explicitly; an energy-unit member without an accompanying energy-consumption member has no effect and SHOULD be omitted. carbon-footprint (numeric): Total gross emissions impact attributable to the reporting subject during the reporting period, expressed in the unit given by carbon-unit (default gCO2e; see that member). The value MUST NOT be negative; see Value Constraints and Omitted Metrics for the treatment of removals and net accounting. carbon-unit (string): The unit of carbon measurement (MUST be one of: gCO2e, kgCO2e, or mtCO2e). When this member is absent, the default gCO2e applies, both to carbon-footprint and to every other member expressed "in the unit given by carbon-unit". A carbon-unit member without any member it parameterizes has no effect and SHOULD be omitted. carbon-accounting (string): "location-based" or "market-based" (following ). scope-1 (numeric): Estimated Scope 1 (direct) carbon emissions. 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 . The value MUST NOT be negative. 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-gCO2e-per-kWh (numeric): Weighted carbon intensity in grams of CO2e per kWh. The value MUST NOT be negative. estimated-annual-emissions-kgCO2e (numeric): Estimated annual gross emissions attributable to the reporting subject, in kilograms of CO2e regardless of carbon-unit. The value MUST NOT be negative. This is an annualized figure: when reporting-period is shorter than a year, it is an extrapolation, and the extrapolation method SHOULD be described in the methodology-uri document. renewable-energy (numeric): Percentage of energy from renewable sources; the value MUST be between 0 and 100 inclusive. 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 or reporting subject, that is, a single document listing links to its public sustainability disclosures (reports, certificates, hosting and energy-source evidence). This document does not constrain the format of that index, and does not define or recommend any path at which it is published: the member carries whatever URI the publisher's disclosure index actually has. A disclosure-uri links to supporting evidence and MUST NOT be treated by clients as proof of the metrics in this document. target-type (string): A hint classifying the reporting subject named by target, to aid machine interpretation of that member. This document defines the values origin (the publishing origin itself; target SHOULD then be the origin's host), path (a resource path prefix on the origin), organization, service, product, device, tenant, and data-source. The member classifies target; it does not change target's syntax or the attribution rules in its definition. A client that does not recognize the value interprets target as if this member were absent (see Value Constraints and Omitted Metrics). The scope-1, scope-2, and scope-3 values are expressed in the unit given by carbon-unit, including its default; sci-score is expressed in grams of CO2e per the declared functional-unit. The three URI-valued members (methodology-uri, verifiable-attestation-uri, and disclosure-uri) MUST be absolute URIs using the "https" (or "http") scheme. Clients MUST NOT automatically dereference a URI member carrying any other scheme, and clients that fetch these URIs SHOULD apply the usual protections against server-side request forgery (SSRF), such as refusing redirects or addresses into private networks. Fields not defined in this specification MAY be present; clients handle members they do not recognize per the ignore-unknown rule in Versioning and Extensibility.

Value Constraints and Omitted Metrics A metric that is not reported for the scope or period covered by an object is omitted from that object. This document defines no in-band "not reported" marker: a member that is present always carries an actual value. Consumers that require a value not present in a Sustainability Metadata Document SHOULD look to the linked disclosure or reporting resources. Several numeric members carry range constraints in their definitions: the gross-quantity members (energy-consumption, carbon-footprint, sci-score, carbon-intensity-gCO2e-per-kWh, and estimated-annual-emissions-kgCO2e) are non-negative, and renewable-energy is bounded to 0-100. carbon-footprint reports gross emissions. Where the declared carbon-accounting methodology supports them, carbon removals, offsets, and net accounting are conveyed through scope-1, scope-2, and scope-3, which MAY be negative for that purpose, or through the linked attestation or disclosure resources; a publisher reporting a negative scope value SHOULD explain the net-accounting basis in the methodology-uri document. A client encountering a defective member value SHOULD NOT reject the document; instead: A value outside a member's stated range (for example, a negative value in a member defined here as non-negative) is treated as not reported. A value of the wrong JSON type (including null) is treated as not reported. An unrecognized value in an enumerated string member defined here (capabilities, energy-unit, carbon-unit, carbon-accounting, or target-type) causes that member to be disregarded. For a unit member, the numeric member(s) it parameterizes are then treated as not reported; for capabilities, the client relies on observed server behavior, as that member's definition directs; for target-type, the client interprets target as if the member were absent. A sci-score unaccompanied by functional-unit is treated as not reported. Note that the CDDL and JTD schemas below close the enumerated value sets. A validating client whose schema check fails only on such a defective value SHOULD apply this tolerance rather than reject the document; a future specification extending one of these sets is expected to publish correspondingly updated schemas. The historical-document case (a document without a target member) is covered in Versioning and Extensibility. A Sustainability Metadata Document (in an array response, at least one of its objects) SHOULD contain at least one reported numeric metric (for example, energy-consumption or carbon-footprint) or at least one of disclosure-uri or verifiable-attestation-uri. A document containing none of these is conformant only by virtue of the mandatory methodology-uri: in that case the publisher MUST ensure that the resource identified by methodology-uri (in an array response, by each object's methodology-uri) provides the substantive disclosure. That resource MUST be publicly retrievable without authentication or payment, MUST describe the measurement or estimation method, and MUST either state the metric values themselves or point directly to where they are published.

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 its definition states, version is an informational provenance label, not a negotiation mechanism, and the label itself never affects client processing. The value space is nevertheless under change control: the labels defined by this document are "1.0", "1.1", and "2.0", and new values are defined only by a future RFC that revises or replaces this document. Publishers MUST NOT mint other values; introducing new members does not, by itself, call for a new value (extension members are covered by the ignore-unknown rule). Extension members. New members may be introduced by a future revision of this specification, or privately by an implementer; the ignore-unknown rule above makes extensions always safe to publish. To make name collisions structurally impossible rather than merely unlikely, member names that do not contain a "." (FULL STOP, U+002E) are reserved for this specification and future documents that revise or replace it. An implementer-defined extension member SHOULD therefore be named using reverse-domain-name notation rooted in a domain the definer controls (for example, com.example.pue for a power-usage-effectiveness figure defined by example.com), consistent with the guidance of . Semantics-free markers such as an "X-" or "vendor-" prefix SHOULD NOT be used. Extension member names are case-sensitive and SHOULD be lowercase, and extension values are subject to the same I-JSON expectations as the rest of the document. No IANA registry is defined for member names: the ignore-unknown rule makes central coordination unnecessary for interoperability, and the reserved undotted name space protects future revisions of this specification. Implementers introducing a member of general interest are encouraged to publish its definition, and such a member may later be adopted (under an undotted name) by a revision of this specification. The values "1.0" and "1.1" denote the historical field set used before the present data model, in which energy-consumption, energy-unit, carbon-footprint, and carbon-unit were mandatory and the reporting subject was conveyed by the optional target-path member (whose absence meant an origin-wide report). The value "2.0" denotes the field set of this document. Documents declaring any of these labels remain valid; per the version definition, the label itself never affects processing. Field-driven tolerance makes historical documents processable: defective values are handled per Value Constraints and Omitted Metrics, and a client that encounters a document without a target member SHOULD treat it as an origin-wide report -- unless the document carries the historical target-path member, in which case the client SHOULD treat that member's value as the reporting subject. A validating client whose schema check fails only because the target member is absent SHOULD apply the same interpretation rather than reject the document.

Formal Definition (CDDL) The following CDDL definition describes the response:

any } ]]>

Formal Definition (JTD) The following JSON Type Definition defines the reporting object:

Range constraints (the non-negativity rules and the 0-100 bound on renewable-energy), the sci-score/functional-unit co-occurrence rule, the date formats of updated and reporting-period, the unit defaults, the URI-member constraints (absolute https/http URIs), and the array-level ordering and uniformity rules are prose rules of this document; they are not captured by the schemas above, and validating implementations enforce them at the application layer.

Example Usage

Basic Response (Root Request) Request: GET /.well-known/sustainability-data This is the common case: a publisher reporting on its own annual cycle, serving a single document with no query parameters, as the Mandatory Minimum Supported Service requires.

Yearly Trend (Monthly Granularity) Request: GET /.well-known/sustainability-data?period=2025&granularity=monthly The response is an array with one object per month; only the first two months are shown here for brevity.

Target-Specific Request (Day Period) Request: GET /.well-known/sustainability-data?target=/api/v1&period=2026-03-15

Target-Specific Yearly Trend (Monthly Granularity) Request: GET /.well-known/sustainability-data?target=/api/v1&period=2026&granularity=monthly As above, the array holds one object per completed month.

Highly Detailed Combined Extended Request Request: GET /.well-known/sustainability-data?target=/app/storage&period=2026-03-20 This example utilizes all optional fields, including GHG Protocol Scopes, a verifiable attestation link to combat greenwashing, the target-type classification hint, and a reverse-domain-named extension member (com.example.pue, a power-usage-effectiveness figure defined by example.com) that clients not recognizing it simply ignore (see Versioning and Extensibility).

Partial Reporting (Omitted Metrics and Default Units) Request: GET /.well-known/sustainability-data In this example the provider reports a carbon figure (for example, from a supplier or a CSRD report) but does not report energy for the period: energy-consumption and energy-unit are simply omitted (see Value Constraints and Omitted Metrics). carbon-unit is also omitted, so the default gCO2e applies to both carbon-footprint and scope-2. The document declares basic capabilities -- no Extended query parameters are supported -- while still carrying optional members, and the disclosure-uri points to where fuller data can be found.

Operational Considerations 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 and . Servers SHOULD set cache directives (e.g., Cache-Control: max-age=86400) . For historical reports, a long max-age (e.g., one year) is RECOMMENDED. Use of ETag and Last-Modified (, Sections 8.8.3 and 8.8.2), enabling conditional requests with If-None-Match, is RECOMMENDED.

Interoperability To maximize interoperability: Servers SHOULD keep their published documents current with this specification. Clients follow the ignore-unknown and version-tolerance rules of Versioning and Extensibility. Implementers SHOULD publish example payloads and test vectors. Aggregators SHOULD document how they map provider fields to their internal models.

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 content delivery networks (CDNs) or reverse proxies MUST ensure that the /.well-known/sustainability-data path is routed to the authoritative publisher or served with the authoritative document. Automation: Providers SHOULD automate updates to the document to reflect changes in energy sourcing or measurement.

Security Considerations

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. Servers SHOULD rate-limit requests to the well-known 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 the target query parameter 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.

Array Size Limits To prevent DoS via memory exhaustion, servers supporting granularity MUST enforce a documented maximum on the 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 (treating the over-broad query as a client error).

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.

Consumer Considerations A Sustainability Metadata Document is untrusted input fetched from an arbitrary origin, and this document deliberately positions it as safe for automated ingestion; consumers are responsible for making that true on their side: Clients SHOULD enforce a response-size limit and bound the number of array entries they accept (the 366-object cap is a server obligation that a client cannot rely on a hostile server to honor). Clients SHOULD bound the time and redirects spent on a single fetch. Clients SHOULD parse the body with a JSON parser hardened against untrusted input, validate against the formal schemas before use, and treat member values as data, never as code or markup. Duplicate member names make JSON interoperability unpredictable (); clients SHOULD reject a document with duplicate names or apply their parser's documented last-value behavior consistently. The URI-valued members carry the dereferencing restrictions and SSRF guidance given in Optional Response Fields.

Greenwashing and Misrepresentation There is a risk that providers publish misleading or incomplete metrics to appear more sustainable. Beyond the mandatory methodology-uri, providers SHOULD link authoritative reports, signed statements, or third-party verification -- for example, cryptographically signed W3C Verifiable Credentials via the verifiable-attestation-uri member. Consumers SHOULD treat the document as a discovery mechanism and validate claims against external sources when necessary.

Privacy and Information Leakage Publishing detailed operational metrics may reveal sensitive information about infrastructure, traffic patterns, or deployment topology. The privacy-related risks of this mechanism -- and the corresponding publisher guidance on aggregation, granularity, fingerprinting noise, and path disclosure -- are consolidated in the Privacy Considerations section.

Integrity and Transport Security As specified in the Mandatory Minimum Supported Service section, the resource SHOULD be served over HTTPS; transport security protects both integrity and privacy of the published metrics. HTTPS is a SHOULD rather than a MUST only because the data is public and some constrained origins are plain-HTTP; consumers with integrity-sensitive uses SHOULD ignore documents not served over HTTPS. Clients MUST validate TLS certificates as required for HTTPS .

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, SHOULD avoid publishing data that could be used to infer internal architecture or expose personally identifiable information, and, when in doubt, SHOULD aggregate or redact fine-grained data. Aggregators SHOULD use privacy-preserving aggregation techniques when publishing derived datasets. Human-readable contact strings (such as the provider member) can carry personal data; role addresses (for example, sustainability@example.com) are RECOMMENDED over personal ones. (See also Privacy and Information Leakage in the Security Considerations.)

Traffic Analysis Servers SHOULD NOT report metrics at a granularity finer than 24 hours, and real-time telemetry is NOT RECOMMENDED: either would allow an observer to correlate energy spikes with specific real-time user actions.

Hardware Fingerprinting Precise metrics can reveal hardware architectures. Servers MAY apply "noise" (fuzzing), as a multiplicative factor bounded within 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 ratios between them (such as a published carbon intensity) are preserved; the noised values are the published values for caching and conditional-request purposes. Members bounded to a range (such as renewable-energy) MUST remain within their stated range after noise. Because ratios are preserved, publishers for whom ratio-based fingerprinting is a concern SHOULD omit the derived members rather than rely on noise. Providers applying noise SHOULD disclose this in the methodology-uri document so that auditors can reconcile published figures with filed reports.

Path Disclosure When the target query parameter 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. For this reason, Optional Extended Query Parameters directs servers to honor the parameter only for a deliberately published set of path prefixes and to respond identically (per the no-data rule) for all other values.

Internationalization Considerations This section classifies every member of a Sustainability Metadata Document according to the distinction BCP 18 , Section 2, draws between protocol elements, which are not localized, and text intended for human consumption, which is. A Sustainability Metadata Document is JSON and is therefore encoded in UTF-8 for interchange (, Section 8.1), so any member value can carry the full range of Unicode characters. Publishers SHOULD emit human-readable strings in Unicode Normalization Form C (, Section 3). Nearly every member of this data model is a protocol element rather than text. Member names, the version label (whose value space is under change control, as Versioning and Extensibility specifies), and the values of the enumerated members (capabilities, energy-unit, carbon-unit, carbon-accounting, and target-type) are ASCII tokens defined by this document; they are compared octet-for-octet, and no case folding, Unicode normalization, or other transformation is applied to them by clients. The updated and reporting-period members carry the date forms specified for them, and the three URI-valued members carry URIs . The RECOMMENDED values of measurement-method are likewise machine-matchable tokens, compared octet-for-octet. The functional-unit member is also a token rather than display text: it is the denominator in which sci-score is expressed, its precise meaning is defined in the methodology-uri document rather than in the string itself, and localizing it would make the accompanying sci-score incomparable. The numeric members carry JSON numbers, which have no language or script dimension; their units are carried by the enumerated unit members above. None of these are translated, and a publisher MUST NOT localize them. The target member is an opaque identifier, as its definition states: it is compared octet-for-octet and MUST NOT be translated or transliterated, since doing so would change which subject it names. Two qualifications follow from what target can name. Where it is a host, the ordinary case-insensitive comparison rules for host names apply, and an internationalized host is given in its A-label form (, Section 2.3.2.1) so that an octet comparison is well defined. Where it is a path prefix, it carries the percent-decoded form, as Optional Extended Query Parameters specifies for a response scoped by the target query parameter. That leaves a small set of members whose values are text for human consumption: provider, a measurement-method value outside the RECOMMENDED set, and any human-readable extension member. Language is conveyed for these at the HTTP layer rather than in the data model, following the approach that problem details (, Sections 1.7 and 3.1.3) takes for its human-readable strings: a server publishing such text in a known language SHOULD send a Content-Language header field (, Section 8.5) identifying it. A server that can produce a document in more than one language MAY select a representation using proactive content negotiation on Accept-Language (, Section 12.5.4), in which case it MUST send a Vary: Accept-Language header field so that caches do not serve one language in place of another. Because these members carry no machine-processable meaning, a client that does not understand the language of a provider string loses no interoperability: the metrics, the units, and the reporting subject are all unaffected. No in-document language-tagging mechanism (such as a map from language tag to string) is defined, since the small set of human-readable values identified above does not warrant one; the pattern used for WebFinger titles (, Section 4.4.4.4) is available to a future revision should localized text within one document ever be needed.

IANA Considerations IANA is requested to register the "sustainability-data" well-known URI in the "Well-Known URIs" registry, following the procedure outlined in . Following the registration template of , Section 3.1: URI Suffix: sustainability-data 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 and follows I-JSON per this document. Formal definitions of the response are provided in this document using CDDL and JSON Type Definition (JTD) . A status of "provisional" is requested in keeping with , 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 suffix "sustainability-data" names the specific application registered here -- a machine-readable data document of sustainability metrics for a declared reporting subject -- rather than claiming the generic term "sustainability" for one convention, in keeping with the precision expectations of , Section 3 (earlier revisions of this document requested the bare suffix "sustainability"). The metadata the URI names is published per origin, which is the pattern for which well-known URIs are appropriate ; 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 and is permitted by , Section 3. Registration is sought to enable interoperable discovery, not to signal endorsement of the publisher's claims.

Acknowledgments Thanks to the early reviewers and to members of the Internet sustainability community who provided feedback on sustainability metadata and discovery patterns.

&RFC2119; &RFC3339; &RFC8174; &RFC7493; &RFC8259; &RFC8610; &RFC8615; &RFC8927; &RFC3986; &RFC9110; &RFC9111; World Resources Institute and World Business Council for Sustainable Development Green Software Foundation &RFC9547; European Parliament and Council United Nations W3C Sustainable Web Interest Group Green Web Foundation European Commission European Parliament and Council &RFC7326; &I-D.ietf-green-terminology; &RFC6454; &RFC7033; &RFC6350; &RFC6648; &RFC2277; &RFC5198; &RFC5890; &RFC9457;

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.

Since -04 This revision responds to the initial Independent Submission Editor review. It changes no member of the data model: none is added, removed, renamed, or retyped, the CDDL and JTD schemas are unchanged, and every document conformant to -04 validates unchanged against this revision's schemas. Removed the sentence in the disclosure-uri definition that named one particular disclosure-index convention as the canonical example and cited two unregistered paths at which it is commonly published, so as not to encourage the use of unregistered well-known names. The member is now stated to be format-agnostic and location-agnostic: this document neither defines nor recommends any path for a disclosure index. The two example documents that used such a value now use a neutral URI on the publisher's own site, and the target definition no longer refers to a site listed in such an index. The carbon.txt convention remains cited, without any path reference, in Relationship to Other Work as adjacent and complementary work. Added an Internationalization Considerations section classifying every member per BCP 18 (RFC 2277), Section 2: member names, the version label, enumerated values, dates, URIs, target, functional-unit, the numeric members, and the RECOMMENDED measurement-method tokens are protocol elements compared octet-for-octet and never localized, while provider, a non-RECOMMENDED measurement-method description, and human-readable extension members are text, for which language is conveyed with Content-Language and MAY be negotiated with Accept-Language (with Vary), following the approach of RFC 9457. The section also gives the comparison rules for a target that names a host (case-insensitive, A-label form for an internationalized host) or a path prefix (percent-decoded). Removed the "free-form" characterization from the running text, which mischaracterized the members it was applied to: measurement-method is described as a token with RECOMMENDED values or otherwise a human-readable description, target as an opaque identifier compared octet-for-octet, target-type as classifying that member rather than a free-form one, and the provider string in Privacy Considerations as human-readable. Stated in the document the rationale for naming whole calendar periods rather than start/end instants (comparability across publishers, a bounded and canonical cache-key space, the reduced-precision calendar dates of ISO 8601 with vCard precedent, and the absence of a normative interval type in RFC 3339), together with the migration path for offset reporting years and the note that an interval form could be added later as a compatible extension. Made the relationship between reporting-period and the period parameter explicit at the point of definition, so the parameter's specification and the rationale above are reachable from the member. Changed the Basic Response example to an annual report ("2025", in kWh and kgCO2e), so that the document's first example shows the case its own recommendation now calls common, and noted at that example that a parameterless annual document is the ordinary deployment. Editorial: folded the single "Caching" subsection directly into Operational Considerations, which contained nothing else, so that section no longer has exactly one child. No normative text changed. Recognized the calendar year as the common reporting cycle: the RECOMMENDED default period of the Basic service is now the period matching the publisher's own reporting cycle, a full calendar year for periodic regulatory-style disclosure or a full calendar month for publishers reporting more frequently. This relaxes a recommendation and invalidates no existing deployment.

Since -03 Renamed the requested well-known URI suffix from sustainability to sustainability-data, following Independent-Stream review feedback on the precision ("squatting") expectations of RFC 8615, Section 3; the document title changed accordingly, and the registration rationale in IANA Considerations was rewritten for the precise name. The Datatracker document name is unchanged. No IANA action had occurred on the previously requested suffix, so no migration or alias mechanism is defined. Added the OPTIONAL target-type member: an enumerated hint (origin, path, organization, service, product, device, tenant, data-source) classifying the reporting subject named by target. Unrecognized values fall under the existing enumerated-member tolerance rule; array responses share one value; added to the CDDL/JTD schemas and to two examples. Placed the version value space under change control: the defined labels are "1.0", "1.1", and "2.0", and new values may be defined only by a future RFC that revises or replaces this document; publishers MUST NOT mint other values. The member itself remains informational-only. Replaced the loose vendor-extension naming advice with a normative "Extension members" rule: member names without a "." are reserved for this specification and its successors; implementer extensions SHOULD use reverse-domain-name notation, avoiding "X-"-style markers per RFC 6648; no IANA member-name registry is created. The worked example member was renamed from vendor-example-pue to com.example.pue. Corrected the CDDL root so an array response requires at least one object ([+ ...]), matching the prose, and fixed a "schemas above"/"below" direction error in Value Constraints. Clarifications from a full review: stated in the Introduction proper that the origin publishes the document while the target member declares what the data is about; required the methodology resource behind the minimum-reporting rule to be publicly retrievable without authentication or payment (and identified it per object in array responses); extended the schema-tolerance note to the historical absent-target case; scoped percent-encoding of the target parameter to characters not permitted in a query component; labeled the "no-data rule" at its definition; broadened disclosure-uri to the origin or reporting subject; neutralized two example methodology URLs; updated the greenwashing guidance to build on the now-mandatory methodology-uri; merged duplicated traffic-analysis wording; listed the date formats among the prose-only rules; noted the carbon.txt convention carries no quantitative metrics; and noted terminology alignment with the IETF GREEN Working Group's terminology document. Final pre-submission audit round (correctness): corrected the legacy-compatibility rule so a historical document carrying target-path is attributed to that subject rather than to the whole origin; qualified the 200-OK requirement for redirects, cache revalidation, and rate limiting; added a Cross-Origin Resource Sharing recommendation (Access-Control-Allow-Origin: *) for browser-based clients, following WebFinger practice; made the array target-type rule all-or-none; extended client tolerance to wrong-JSON-type (including null) values and to sci-score without functional-unit, restructuring the tolerance rules as a list; defined granularity without period (applies to the default period) and separated malformed from unrecognized parameter values; specified that target matching is performed after percent-decoding; stated the client behavior for an empty array; required range-bounded members to stay in range after anti-fingerprinting noise, and corrected the noise-consistency example to ratio preservation; required a documented array-size maximum. Final pre-submission audit round (editorial): consolidated duplicated normative statements to single owning locations (the ignore-unknown rule, version tolerance, the target parameter/member distinction and echo rule, the range constraints, the published-prefix rule, the unit defaults, and the greenwashing attestation guidance); rescaled the day-period path-scoped example for plausibility against its monthly counterpart; expanded GHG, ESRS, SSRF, and CDN at first use and set the header workgroup label to "Independent Submission"; merged the duplicated DoS motivation sentence; noted that non-uniform members (for example, capabilities) are unconstrained across array entries; and other minor wording polish.

Since -02 This revision is a breaking change to the data model and wire format; documents and clients built to -02 ("1.0"/"1.1") interoperate with -03 ("2.0") consumers only through the compatibility rules in Versioning and Extensibility. Examples now declare version "2.0". Removed the negative "not reported" sentinel entirely: an unreported metric is now conveyed by omitting the member. Negative values are no longer special: gross-quantity members (energy-consumption, carbon-footprint, sci-score, carbon-intensity-gCO2e-per-kWh, estimated-annual-emissions-kgCO2e) MUST be non-negative, renewable-energy is bounded 0-100, and scope-1/2/3 MAY be negative to express removals or net accounting (resolving the previous gap for net-negative scope reporters). Clients encountering a negative value in a non-negative member treat it as not reported, preserving compatibility with historical sentinel-bearing documents. Made energy-consumption, energy-unit, carbon-footprint, and carbon-unit OPTIONAL. When a value member is present and its unit member is absent, wire-level defaults apply: kWh for energy and gCO2e for carbon (the carbon default also parameterizes scope-1/2/3). Added a minimum-reporting rule: a document SHOULD carry at least one reported numeric metric or a disclosure-uri/verifiable-attestation-uri; a document carrying none is conformant only because the publisher MUST ensure the mandatory methodology-uri leads to the substantive disclosure. (Replaces the -02 rule about documents with both required metrics unreported.) Renamed the optional target-path member to target, made it MANDATORY, and generalized it to identify the reporting subject (origin host, RECOMMENDED for origin-wide reports; path prefix, organizational entity, cloud tenant or provider scope, software source, or carbon.txt-listed site). A response scoped by the target query parameter echoes the matched prefix in the target member; the previous "absence means origin-wide" rule is removed (the member is always present). Array responses now uniformly share one target value. Renamed carbon-intensity-gCO2-per-kWh to carbon-intensity-gCO2e-per-kWh and estimated-annual-emissions-kgCO2 to estimated-annual-emissions-kgCO2e, aligning all carbon quantities on the CO2e (CO2-equivalent) convention; stated that the annual figure is an extrapolation whose method belongs in the methodology document. Redefined capabilities to describe query-parameter support only ("basic" = minimum service; "extended" = Extended parameters supported); a "basic" document MAY carry optional members. The mandatory member set is now: version, updated, capabilities, provider, measurement-method, methodology-uri, reporting-period, target (8 of the 23 defined members). Versioning: "1.0"/"1.1" now denote the historical pre-2.0 field set; "2.0" denotes this revision. version remains informational-only (clients MUST NOT reject or branch on it); compatibility with historical documents is achieved through field-driven tolerance rules. Replaced the "Not-Reported Sentinel" example with a "Partial Reporting" example (carbon reported, energy omitted, default units, basic with optional members); added target to all examples; added a worked vendor-extension member (vendor-example-pue) to the detailed example. Added an applicability paragraph to the Introduction describing the convention's web, machine-to-machine/API, human-reader, and automated-agent/AI readiness. Consolidated the privacy material: the Security Considerations "Privacy and Information Leakage" subsection now defers to the Privacy Considerations section; the HTTPS requirement is stated once (Mandatory Minimum Supported Service) and cross-referenced from Integrity and Transport Security; corrected the target bullet's cross-reference to point at Privacy Considerations, Path Disclosure. Editorial: HEAD responses now use MUST (parallel to GET); the updated member cites RFC 3339 formally; expanded the CDDL and JTD abbreviations on first use; cited ESRS E1 formally and tied Digital Product Passports to the EU ESPR; updated the W3C-WSG reference to its current Group Draft Note form; forward-referenced the "Sustainability Metadata Document" definition at first use; aligned the prose/CDDL/JTD member ordering; noted that the formal schemas cannot express the range constraints and unit defaults; removed trailing whitespace. For the historical record: the weekly granularity value, introduced in the predecessor draft draft-besleaga-green-sustainability-wellknown-01, was removed before the present document series began; the defined granularity values are monthly and daily (this note keeps the in-document changelog in lockstep with the repository CHANGELOG, corrected in the same pass).

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. 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). 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.

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.

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" (a section since removed). Also noted that carbon-footprint is gross (non-negative) and that the anti-fingerprinting noise is not applied to the "not reported" sentinel. 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.