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
