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 <pkyzi...@alum.mit.edu> 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 <pkyzi...@alum.mit.edu> 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
_______________________________________________
Gen-art mailing list -- gen-art@ietf.org
To unsubscribe send an email to gen-art-le...@ietf.org
