Re: Gen-ART Last Call review of draft-ietf-httpbis-cache-groups-03

Hi Jeffrey,

> On 26 Feb 2025, at 6:41 am, Jeffrey Yasskin <jyasskin@google.com> wrote:
> 
> 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.)

RFC2119 keywords are reserved for requirements that ensure interoperability. The examples you give are descriptive statements: they indicate how a party that wishes to achieve a particular goal should proceed. That's not about interop, however. In the specs I write, I try (but sometimes fail) to distinguish carefully between these uses.

> 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.

It's a MAY there because the specification doesn't place any additional requirements on existing caches -- keep in mind that HTTP already invalidates cache on every POST, PUT, etc. 

It's really designed to be used in concert with mechanisms like Targeted Cache Control, as per the following paragraph.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 4 March 2025 06:12:18 UTC