- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 18 Jan 2022 15:01:02 +1100
- To: Benjamin Kaduk <kaduk@mit.edu>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-targeted-cache-control@ietf.org, httpbis-chairs@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, tpauly@apple.com
Hi Ben, > On 18 Jan 2022, at 9:46 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote: > > 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 . Thanks. I've left a review there. > 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.) Yes, although the main focus here was on future directives that take advantage of them. > 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. I'm at a loss as to how, except perhaps for expanding "this" into an example in the following sentence. Do you have any suggestions? > 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. I think it's a given, if you consider how often such mechanisms have been independently created and used throughout the history of the web. > 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? I don't think it is safe, because that leads to the construction "When a cache [] receives a response with one or more of the header field names on its target list, the cache [] MUST ignore the Cache-Control and Expires header fields in that response." Which doesn't cover the invalid/empty case. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 18 January 2022 04:01:22 UTC