- From: Marco Tiloca <marco.tiloca@ri.se>
- Date: Fri, 28 Feb 2025 09:50:52 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: art@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
- Message-ID: <4374b594-25df-4aa6-ae10-145d2fc3b0d7@ri.se>
Hi Mark, Looks good, thanks a lot for addressing my comments. Best, /Marco On 2025-02-28 01:33, Mark Nottingham wrote: > Hi Marco, > > See: > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fcommit%2Fb3720fdf0&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd4fc8c8e5bb64cd742f208dd578f90ac%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638762996325438852%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jWkbnJNVKiWpo7bsE86Uj5u3WLG%2BctZNF3%2FZUMRjHZ4%3D&reserved=0 > > Regarding receiving both headers: ordering of processing shouldn't matter, because HTTP already has invalidation semantics for POST responses; see > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%2Fspecs%2Frfc9111.html%23invalidation&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd4fc8c8e5bb64cd742f208dd578f90ac%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638762996325456177%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SBYuExtN6a8ggfDLW4x3ewXo9xrStIXnb9FwPvLDwXY%3D&reserved=0 > > Cheers and thanks, > > >> On 25 Feb 2025, at 11:57 pm, Marco Tiloca via Datatracker<noreply@ietf.org> wrote: >> >> Reviewer: Marco Tiloca >> Review result: Ready with Nits >> >> I reviewed this document as part of the Applications and Real-Time (ART) Area >> Review Team's ongoing effort to review all IETF documents being processed by >> the IESG. These comments were written primarily for the benefit of the ART Area >> Directors. Document authors, document editors, and WG Chairs should treat these >> comments just like any other IETF Last Call comments. >> >> Thanks for this document! I believe it is basically ready. >> >> Please see below a few minor comments. >> >> Best, >> /Marco >> >> [Section 1] >> >> * It says: >> >>> Section 2 introduces a means of describing the relationships between a set >> of stored responses in HTTP caches by associating them with one or more >> opaque strings. It also describes how caches can use that information to >> apply invalidation events to members of a group. >> >> If I understand correctly: >> >> * "set" in the first sentence is what "group" means in the second sentence. >> >> * The "opaque strings" in question are practically the names given to the >> groups. >> >> * If the strings are opaque, I'm not sure how much they are about >> "describing" relationships. I suppose that what actually reflects the >> relationships is the group memberships of the cached responses. >> >> If the above is correct, a possible rephrasing is: >> >>> Section 2 introduces a means of describing the relationships between stored >> responses in HTTP caches, by associating those responses with one or more >> groups that reflect their relationships and that are identified by opaque >> strings. It also describes ... >> >> A rephrasing along the same lines can apply to the abstract too. >> >> [Section 2.1] >> >> * It says: >> >>> to have the same group ... >> I guess it means: >> >>> to belong to the same group ... >> [Section 3] >> >> * It says: >> >>> For example, a POST request that has side effects on two cache groups could >> indicate that stored responses associated with either or both of those groups >> should be invalidated with: >> >> I think you mean: >> >>> For example, following the successful processing of a POST request that has >> side effects on two cache groups, the corresponding response could indicate >> that ... >> >> * Even though hardly useful, it seems admitted that: >> >> * A response includes both the Cache-Groups header field and the >> Cache-Group-Invalidation header field; and >> >> * Both header fields include the same string "foo". >> >> In that case, is it still entirely up to the cache receiving the headers to >> decide whether first associating the response with the group "foo" and then >> optionally removing the response from that group, or instead doing vice versa? >> >> Would a specific processing order be desirable/expected? For example, first >> process the Cache-Group-Invalidation header and then the Cache-Groups header, >> in case both are present in a response. >> >> [Nits] >> >> * Section 1 >> --- s/address this issues/address the issues >> >> * Section 2.1 >> --- s/The both/They both >> >> * Appendix A >> >> The "Acknowledgements" section is usually an unnumbered section after the >> appendices (if any), see RFC 7322. >> >> >> > -- > Mark Nottinghamhttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cd4fc8c8e5bb64cd742f208dd578f90ac%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638762996325467739%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8wdQ6mdGQg6lTDL71%2BPWLXov21besgcsTWLea4yCjaA%3D&reserved=0 > -- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Thursday, 22 May 2025 07:10:07 UTC