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

[Mark Nottingham <[e-mail]>]

Hi Ben,

> On 18 Jan 2022, at 9:46 am, Benjamin Kaduk via Datatracker <[e-mail]> 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/