W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2022

Re: Benjamin Kaduk's Yes on draft-ietf-httpbis-targeted-cache-control-03: (with COMMENT)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 18 Jan 2022 15:01:02 +1100
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
Message-Id: <1727DC74-19A7-4AAC-ABEE-F7E6F6C2D8A8@mnot.net>
To: Benjamin Kaduk <kaduk@mit.edu>
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?

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


Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 18 January 2022 04:01:22 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 18 January 2022 04:01:24 UTC