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

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

From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
Date: Mon, 17 Jan 2022 14:46:11 -0800
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-httpbis-targeted-cache-control@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com, tpauly@apple.com
Message-ID: <164245957049.28420.12473795777106711821@ietfa.amsl.com>
Benjamin Kaduk has entered the following ballot position for
draft-ietf-httpbis-targeted-cache-control-03: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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

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


Section 1

   Because it is often desirable to control these different classes of
   caches separately, some means of targeting directives at them is

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?
Received on Monday, 17 January 2022 22:46:25 UTC

This archive was generated by hypermail 2.4.0 : Monday, 17 January 2022 22:46:26 UTC