I think Paul's looking in the wrong place for the normative requirement (that is, I like the style that Structured Fields uses to define headers, and the use of "X header is a List ..."), but I'm also having trouble finding the actual requirements on the sender and receiver in https://www.ietf.org/archive/id/draft-ietf-httpbis-cache-groups-03.html.
For example, I'd expect something like "A cache group is a set of HTTP responses that caches should invalidate at the same time. HTTP servers SHOULD identify each cache group with a string name. When sending a response, HTTP servers SHOULD include a Cache-Groups response header whose content is the list of names of the cache groups that response belongs to, which MUST be serialized according to section 4.1.1 of RFC 9651." (I haven't looked through HTTP and STRUCTURED-FIELDS recently enough to be sure I'm using exactly the right terminology in that suggestion, but I think it's close.)
On the parsing side, https://www.ietf.org/archive/id/draft-ietf-httpbis-cache-groups-03.html#section-2.2 is close. It's missing the formal "a cache MUST parse the Cache-Groups response header according to section 4.2.1 of RFC 9651", but, honestly, I don't think that will cause any interoperability problems and so it isn't all that necessary. I also wonder if the MAY should be strengthened to SHOULD. After all, the cache can remove stored responses at any time anyway, and so a MAY statement isn't adding anything.
Jeffrey
On Tue, Feb 25, 2025 at 9:27 AM Paul Kyzivat <pkyzivat@xxxxxxxxxxxx> wrote:
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
