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

Hi Mark,

On Tue, Jan 18, 2022 at 03:01:02PM +1100, Mark Nottingham wrote:
> Hi Ben,
> 
> > On 18 Jan 2022, at 9:46 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
[...]
> > 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.

That makes a lot of sense.

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

Thinking about it a bit more, it seems like the way to avoid confusion (and
what the "careful use" would be achieving) is some form of (e.g.,
out-of-band) coordination between producer and consumer.  So, something
like "confusion ... in different systems, absent some mechanism for
coordination" is a direction to consider.  Your proposal of expanding the
"this" in the following sentence (not quoted) is also promising.  Doing
both is likely overkill (and doing nothing would also be fine, to be
clear).

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

It seems that Rob's review prompted the sort of example I was looking for
-- thanks for that.

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

Okay, you convinced me.

Thanks again,

Ben

Received on Thursday, 20 January 2022 20:39:46 UTC