]> Independent

andrei.besleaga@ieee.org

Internet-Draft Sustainability Carbon Accounting Well-Known URI Energy Efficiency 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.

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

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

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, origin-level environmental metrics. 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. 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. 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.

The "sustainability" Well-Known URI

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.

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

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

Payload Format (JSON Data Model) A successful response MUST return, with the media type application/json, either a single JSON object 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.

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

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.

Optional Response Fields The JSON object MAY contain the following OPTIONAL keys to align with the , 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 ). 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 . 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 , 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.

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.

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

any } ]]>

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

Example Usage

Basic Response (Root Request) Request: GET /.well-known/sustainability

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.

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

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.

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.

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.

Operational Considerations

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 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 MUST tolerate unknown fields and future versions. 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 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.

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

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.

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.

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.

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.

Integrity and Transport Security The resource SHOULD be served over HTTPS to protect integrity and privacy. Clients MUST validate TLS certificates according to standard practice.

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.

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.

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.

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.

IANA Considerations IANA is requested to register the "sustainability" well-known URI in the "Well-Known URIs" registry, following the procedure outlined in . This registration enables interoperable discovery of sustainability metadata. Following the registration template of , 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 and SHOULD follow I-JSON . 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 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 . 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 Design Community Group Green Web Foundation &RFC7326; &RFC7033;

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