Re: [Green] New Draft: The Sustainability Well-Know URI

Hi GREEN and SUSTAIN members,

Following the recent update to version -03, I wanted to thank Michael
Sweet for cross-posting this to the SUSTAIN list.

Version -03 specifically addresses the "rebound effect" of carbon
metadata by ensuring out-of-band reporting. It also includes many
improvements for a standard well-known location discovery and some
basic information in-line with other standards.

To facilitate review, I have published some full JSON samples, a
validation suite, and some configs for servers, on GitHub:
https://github.com/andreibesleaga/rfc-sustainability-wellknown

I also wanted to improve the code repository. I'm considering
integrating existing open-source software libraries to output standard
or extended JSON, depending on the implementation. This would result
in a complete server-side project, provided I have enough time. Let me
know what you think, if you know of other existing efforts, or if
anyone would want participation.

I am curious if members of the WG SUSTAIN list see any conflicts with
other existing standards (or sustainability reporting frameworks), or
if this discovery mechanism aligns with their current requirements,
and also if this version would be ready for adoption by WG GREEN.

I look forward to your response or any questions I can clarify to help
improve v03.

Best regards,
Andrei Besleaga

On Sun, Mar 22, 2026 at 1:55 PM Andrei Besleaga
<andrei.besleaga@ieee.org> wrote:
>
> Yes, I think having the basic/extended capabilities and schema versioning would allow any further improvements (even after/if becomes a standard).
>
> Thank you,
> Andrei.
>
>
> On Sat, Mar 21, 2026, 22:13 Michael Sweet <msweet=40msweet.org@dmarc.ietf.org> wrote:
>>
>> Andrei,
>>
>> > On Mar 21, 2026, at 12:02 PM, Andrei Besleaga <andrei.besleaga=40ieee.org@dmarc.ietf.org> wrote:
>> >
>> > Thanks Michael,
>> >
>> > About the Quarterly I removed it since I thought would be better for the standard to cover "normal dates" (from the RFC datetime format and easier for implementing technically in some universal SQL/NoSQL formats).
>> >
>> > Also was thinking if there is already a yearly query param period (with monthly granularity),  and is in recommendations to have the yearly stuff cached, then maybe this would suffice to have only yearly, monthly, daily (with monthly/daily granularity), would cover all cases (up to a year), and optimized enough for same further queries (and if an auditor would want a larger period than monthly or some days, they probably would want longer periods, they would derive easily from 12 months result, the 4 quarters).
>>
>> That will probably be sufficient, but we can always extend things later as needed...
>>
>> ________________________
>> Michael Sweet
>>

Received on Thursday, 26 March 2026 14:49:08 UTC