Ballot for draft-ietf-httpbis-targeted-cache-control
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Thanks for this clear and useful document; also for the helpful shepherd writeup. I have a nit, and a question: 1. §2.1 Nit: Implementations SHOULD NOT consume values that violate these inferred constraints. For example, a consuming implementation were to coerce a max-age with a decimal value into an integer would behave differently than other implementations, potentially causing interoperability issues. I think “were to coerce” should be “that were to coerce”. 2. I have a question regarding one of the examples in §3.1: Whereas these would prevent all caches except for CDN caches from storing the response: Cache-Control: no-store CDN-Cache-Control: none (note that 'none' is not a registered cache directive; it is here to avoid sending a header field with an empty value, which would be ignored) As a httpbis naïf, I might have guessed that a field that contains no registered directive might be considered equivalent to an empty field, in which case according to the rules of §2.2 the field would be ignored and the Cache-Control field would be respected instead. Your example makes it clear that guess would be wrong, thank you. My question is whether it’s completely obvious to those conversant with the subject area, that it’s fine to just bung a random string into the field? For that matter, supposing someone came along and registered 'none' at some point in the future. Might that cause the example case to break?
Much thanks to Joel for the OpsDir review, and thanks to the authors and WG for this document...
Thanks for working on this specification. I have only one observation - CND-Cache-Control is a targeted for CDN caches, however, my understanding is this can end up in the clients. There is no description or reference to description about what a client supposed to handle this (obvious is to ignore). It would be great if we can write something about it or refer to the client behavior description elsewhere. If my understanding is wrong that this header field will never reach any client then I would say it requires some wording in the specification to clearly state that.
Thank you for the work put into this document. Even not being a specialist, the interest of the document is clear (and the document itself is easy to read). Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tommy Pauly for the shepherd's write-up including the section about the WG consensus (and be clear about that I-D is mainly the work of 3 CDNs). I hope that this helps to improve the document, Regards, -éric Generic comment: while the document appears to be very generic (barring my comment below), it actually only requests IANA for a "CDN-Cache-Control" targeted header, I.e., should this be reflected in the title ? -- Section 1 -- Is there any reason why the enterprise caches/proxies are not mentioned in the first § ? -- Section 2.2 -- As the target list is merely a local decision, why are the behaviours specified as a "MUST" and not as a "SHOULD" ? I.e., after all it is all local decisions and there could be local constraints/restrictions. There is also no negotiation between the cache and its upstream cache/origin that could contractually bind the 2 parties. == NITS == -- Section 1 -- In "a Web site", does "web" really deserve being capitalised ? -- Section 2.1 -- In "as if the field were not present" should field be in the plural form ?
Thanks for responding to the gen-art reviewer with the remark about the "publisher site" link for the [AGE-PENALTY] reference. I would not have followed that link without the extra nudge, and wonder if it could be incorporated somehow into the document. Perhaps the RFC Editor has thoughts... I put some very minor editorial thoughts in https://github.com/httpwg/http-extensions/pull/1890 . Section 2.1 Parameters received on directives are to be ignored, unless other handling is explicitly specified. I assume that the "other handling" could be specified in many ways, including but not limited to some future RFC and explicit administrator configuration. (Which, to be clear, suggests no change to this text.) Section 5 The ability to carry multiple caching policies on a response can result in confusion about how a response will be cached in different systems, if not used carefully. [...] The "if not used carefully" is probably not how I would have phrased it. It's possible to try to use it carefully and still (Murphy's Law) have things go awry, after all. I don't have any suggestions other than just removing the clause, though, which I recognize is a pretty heavy hammer -- some additional clarification here is worthwhile, if we can wordsmith it. NITS Section 1 Because it is often desirable to control these different classes of caches separately, some means of targeting directives at them is necessary. This feels a bit like begging the question -- it doesn't actually present any supporting evidence for separation of control as desirable; rather, it just assumes that it is desirable. Some example of where divergent behavior by different caches is useful might be helpful. Section 2.2 When a cache that implements this specification receives a response with one or more of of the header field names on its target list, the cache MUST select the first (in target list order) field with a valid, non-empty value and use its value to determine the caching policy for the response, and MUST ignore the Cache-Control and Expires header fields in that response, unless no valid, non-empty value is available from the listed header fields. As I understand it, the final "unless no valid, non-empty value is available" is redundant with the previous "MUST select the first (...) field with a valid, non-empty value and use its value". But it seems kind of confusing to have that listed twice, as it invites the reader to invent some other reason for having the second statement. Is it safe to just drop the final clause of the sentence?
Thanks to Elwyn Davies for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/LgEyhFr95SkeHZGTiJbsM2xKO7I). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "Table of Contents", paragraph 2, nit: > layers of caching. For example, a Web site might use a cache on the origin se > ^^^^^^^^ Nowadays, it's more common to write this as one word. Section 1. , paragraph 5, nit: > ield (hereafter, "targeted field") is a HTTP response header field that has t > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Section 2.2. , paragraph 1, nit: > eceives a response with one or more of of the header field names on its targe > ^^^^^ Possible typo: you repeated a word.
Hi, Thanks for this document, and thanks Joel for the opsdir review. A few comments: 1. Because it is often desirable to control these different classes of caches separately, some means of targeting directives at them is necessary. As a reader that is not familiar with the reasons (but I could potentially guess), I was wondering whether it would be help to add a sentence to explain why this might be done? 2. I felt a bit ambiguous to me about what directives are actually allowed in a cache directive: Section 2.1 states: "Targeted fields are Dictionary Structured Fields (Section 3.2 of [STRUCTURED-FIELDS]). Each member of the dictionary is a cache response directive from the Hypertext Transfer Protocol (HTTP) Cache Directive Registry (https://www.iana.org/assignments/http-cache- directives/)." and If a targeted field in a given response is empty, or a parsing error is encountered, that field MUST be ignored by the cache (i.e., it behaves as if the field were not present, likely falling back to other cache control mechanisms present) Section 3.1 states: Cache-Control: no-store CDN-Cache-Control: none (note that 'none' is not a registered cache directive; it is here to avoid sending a header field with an empty value, which would be ignored) It was left somewhat unclear to me whether an implementation is allowed to use a cache directive that is not defined in the "Cache Directive Registry", noting that the example in 3.1 seems to suggest this is allowed. Perhaps the document would be clearer if this was explicitly stated in section 2.1? Some nits: more of of => more of \[CDN-Cache-Control]]) => strange escape or extra ]. "directive" to "Cache directives" in a few more places for consistency? Particularly in section 2.1, I thought that this might make the text slightly better. Thanks, Rob