Robert Wilton's No Objection on draft-ietf-httpbis-targeted-cache-control-03: (with COMMENT)

Robert Wilton has entered the following ballot position for
draft-ietf-httpbis-targeted-cache-control-03: No Objection

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:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-targeted-cache-control/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document, and thanks Joel for the opsdir review.

A few comments:

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

As a reader that is not familiar with the reasons (but I could potentially
guess), I was wondering whether it would be help to add a sentence to explain
why this might be done?

2. I felt a bit ambiguous to me about what directives are actually allowed in a
cache directive:

Section 2.1 states:
  "Targeted fields are Dictionary Structured Fields (Section 3.2 of
   [STRUCTURED-FIELDS]).  Each member of the dictionary is a cache
   response directive from the Hypertext Transfer Protocol (HTTP) Cache
   Directive Registry (https://www.iana.org/assignments/http-cache-
   directives/)."

   and

   If a targeted field in a given response is empty, or a parsing error
   is encountered, that field MUST be ignored by the cache (i.e., it
   behaves as if the field were not present, likely falling back to
   other cache control mechanisms present)

Section 3.1 states:

   Cache-Control: no-store
   CDN-Cache-Control: none

   (note that 'none' is not a registered cache directive; it is here to
   avoid sending a header field with an empty value, which would be
   ignored)

It was left somewhat unclear to me whether an implementation is allowed to use
a cache directive that is not defined in the "Cache Directive Registry", noting
that the example in 3.1 seems to suggest this is allowed.  Perhaps the document
would be clearer if this was explicitly stated in section 2.1?

Some nits:

more of of => more of

\[CDN-Cache-Control]]) => strange escape or extra ].

"directive" to "Cache directives" in a few more places for consistency? 
Particularly in section 2.1, I thought that this might make the text slightly
better.

Thanks,
Rob

Received on Tuesday, 18 January 2022 18:15:57 UTC