Mark,
We seem to be talking past on another.
I get it that you have deferred the syntax to [STRUCTURED-FIELDS], and I
am not reviewing that.
My point is that the directive in your document to follow the
specification in [STRUCTURED-FIELDS] is not itself clearly normative.
The statement:
"The Cache-Groups HTTP Response Header is a List of Strings
[STRUCTURED-FIELDS]."
doesn't stand out to me as a normative reference that MUST be followed.
It is what I might expect to see for an informative reference.
But I'm just a GenArt reviewer. At the end of the day you can do as you
wish. I get the sense that this sort of specification is common in this
realm.
Thanks,
Paul
On 2/24/25 11:22 PM, Mark Nottingham wrote:
Hey,
Specifying interoperability in terms of what artifacts look like on the wire doesn’t take into account divergence of behavior between sending and receiving, leading to security as well as interop issues - especially when there are many potential producers and/or consumers of the artifact (as is often the case with web protocols).
That’s why we’ve taken the approach of specifying parsing and serialisation behaviors separately in structured fields, mirroring the approach that’s taken in many other modern parts of the web stack such as html.
Cheers,
Sent from my iPhone
On 25 Feb 2025, at 3:10 pm, Paul Kyzivat <pkyzivat@xxxxxxxxxxxx> wrote:
Ho Mark,
On 2/24/25 6:41 PM, Mark Nottingham wrote:
Hi Paul,
Thanks for the review; responses below --
On 25 Feb 2025, at 4:36 am, Paul Kyzivat <pkyzivat@xxxxxxxxxxxx> wrote:
1) NIT: Lack of normative language for syntax
I gather this document intends to normatively specify some of the syntax of HTTP requests and responses. Yet the specification fails to use normative language. For instance, consider the following sentence from section 2:
"The Cache-Groups HTTP Response Header is a List of Strings [STRUCTURED-FIELDS]."
To clearly be normative, I would expect this to be stated as:
"The Cache-Groups HTTP Response Header MUST be a List of Strings [STRUCTURED-FIELDS]."
This problem is present in sections 2 and 3, and also in the reference [STRUCTURED-FIELDS].
We avoid that style of requirement, because it doesn't make clear who the requirement applies to, or how to handle failures. Structured fields requires (in section 1.2) use of specific algorithms that address that shortcoming.
I don't understand. Are you saying that replacing "is" by "MUST be" makes the requirement less clear?
I've heard many stories of implementers who only feel obligated to implement the parts of a spec that say "MUST". I don't agree with that approach, but it is out there. Using the BCP 14 keywords to express normative intent helps to reduce questions about normative intent.
Thanks,
Paul
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
