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=""> 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=""> Cheers and thanks,On 25 Feb 2025, at 11:57 pm, Marco Tiloca via Datatracker <noreply@xxxxxxxx> 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 setof 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 storedresponses 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 couldindicate 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 hasside 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 Nottingham https://eur05.safelinks.protection.outlook.com/?url="">
-- 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
Attachment:
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
