Early Review of draft-besleaga-sustainability-wellknown-07
review-besleaga-sustainability-wellknown-07-artart-early-bray-2026-10-03-00

This is the ART area review of the draft.

I don't know anything about the subject so am not commenting on the
sustainability semantics it supports.I found the draft not very well written;
in particular, excessively verbose. After reviewing, I submitted the text of
the first few sections to Pangram, which reported 97% of the text was
AI-generated. I think in future I'll check with Pangram first and decline
slop-drafts. I think the list of issues below require a "Not Ready" status.

The document uses the term "subject" but the field in the JSON is "target". Why
2 different names for the same thing?

There are quite a few things that are required to be absolute URIs.  I can
think of scenarios where relative URIs would be operationally useful - if I
were a service provider offering a service where I generate sustainability data
for site operators, it might be nice to have extensions and targets which are
relative URIs so I can ship a self-contained package.

1.3 "Ignore any top-level member it does not recognize, and any extensions
entry it does not implement." Elsewhere we have "A declaration object contains
the seven mandatory members, any of the optional members, and nothing else: a
publisher MUST NOT add other top-level members". So does the presence of
another top-level member constitute an error, or not?

In 2.1, there's a list: Origin, Declaration, etc. What is this a list of? I
think it's a list of terms, maybe this should be with the 2119 stuff up in 1.1,
or a separate "Spec-specific Terminology" section? It doesn't feel like it
should be in a section entitled "URI definition"

"Reporting subject: the entity or scope the metrics describe, named by the
mandatory target member." Now we have the terms "subject", "target", and
"Reporting subject"

A lot of the material in 2.2 feels duplicative of basic HTTP semantics, maybe
much of the section could be replaced with references to RFC9110?

2.4 "a server" should be "the origin"?

Once again, the material in 2.4 may be unnecessarily duplicative of the
specification of query parameters for HTTP?

Why is the name "methodology-uri" rather than just "methodology"?  In code, we
typically don't use names like "length_int"

The "document identified by methodology-uri" thing is troubling, in that none
of this stuff will work if you can't determine certain things from its content,
but the spec doesn't say anything about the data format. Should this be
standardized a little more?

2.5 "The body is one declaration object [RFC8259] or an array of them" Maybe
worth noting that an array of objects is a valid JSON text per 8259, and by
"array" you mean JSON array, i.e. it has to be enclosed in a single "[", "]"
pair.

2.5.1 "It is an opaque protocol element that MUST NOT be translated or
transliterated, compared octet-for-octet except where" I *think* this saying it
MUST be compared octet-for-octet, right? Maybe make that explicit, it's not
100% clear where the scope of the preceding MUST NOT ends.

2.5.1 Why does the methodology-uri have to be absolute? Can't an origin also
host a methodology doc?

Should "target-type" be one of the required fields?  I can't find where its
semantics are defined, but there are several references on how to use it.

2.5.4 "a scheme, a hier-part, an optional query, and no fragment, written in
ASCII with the scheme in lowercase." Once again, duplicative of 3986?