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

Hi Rob,

> On 19 Jan 2022, at 5:15 am, Robert Wilton via Datatracker <> wrote:
> 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?

I've added a motivating example here:

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

Hm. Yes, the invocation of the registry is a bit odd there. I've attempted to improve this here:
(co-authors, please review)

> 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 for the review.

Mark Nottingham

Received on Thursday, 20 January 2022 04:07:59 UTC