Code change:
2.2. <del> Targeted fields MAY be parsed as a Dictionary Structured Field RFC8941, and implementations are encouraged to use a parser for that format in the interests of robustness, interoperability and security. When an implementation parses a targeted field as a Structured Field, each cache directive will be assigned a value.  For example, max-age has an integer value; no-store's value is boolean true, and no- cache's value can either be boolean true or a list of field names. Implementations SHOULD NOT accept other values (e.g. coerce a max-age with a decimal value into an integer).  Likewise, implementations SHOULD ignore parameters on directives, unless otherwise specified. However, implementers MAY reuse a Cache-Control parser for simplicity.  If they do so, they SHOULD observe the following points, to aid in a smooth transition to a full Structured Field parser and prevent interoperability issues: </del> <ins> Targeted fields are defined as Dictionary Structured Fields (Section 3.2 of STRUCTURED-FIELDS).  Each member of the dictionary is a cache directive from the Hypertext Transfer Protocol (HTTP) Cache Directive Registry. Because cache directives are not defined in terms of structured data types, it is necessary to map their values into the appropriate types.  Typically, they are mapped into a Boolean (Section 3.3.6 of STRUCTURED-FIELDS) when the member has no separate value, a Token (Section 3.3.4 of STRUCTURED-FIELDS) for alphanumeric values, a String (Section 3.3.3 of STRUCTURED-FIELDS) for quote-delimited values, or an Integer (Section 3.3.1 of STRUCTURED-FIELDS) for purely numeric values. For example, the max-age directive (Section 5.2.2.1 of HTTP-CACHING) has an integer value; no-store (Section 5.2.2.5 of HTTP-CACHING) always has a boolean true value, and no-cache (Section 5.2.2.4 of HTTP-CACHING) has a value that can either be boolean true or a string containing a comma-delimited list of field names. Implementations SHOULD NOT generate or consume values that violate these inferred constraints on the directive's value (e.g. coerce a max-age with a decimal value into an integer).  Likewise, implementations SHOULD ignore parameters on directives, unless otherwise specified. Sending implementations MUST generate valid Structured Fields. Receiving implementations SHOULD use a Structured Fields parser, but MAY reuse an existing parser for the Cache-Control field value (Section 5.2 of HTTP-CACHING).  In doing so, they SHOULD implement the following constraints, to aid in a smooth transition to a full Structured Field parser and prevent interoperability issues: Directive names are all lowercase (e.g., "MAX-AGE=60" is considered an error). </ins> If a directive is repeated in the field value (e.g., "max-age=30, <del> max-age=60"), the last value 'wins' (60, in this case) </del> <ins> max-age=60"), the last value 'wins' (60, in this case). </ins> Members of the directives can have parameters (e.g., "max- age=30;a=b;c=d"), which should be ignored unless specified. If a targeted field in a given response is empty, or a parsing error <del> is encountered (when being parsed as a Structured Field), that field SHOULD be ignored by the cache (i.e., it should behave as if the field were not present, likely falling back to other cache control mechanisms present). </del> <ins> is encountered, that field SHOULD be ignored by the cache (i.e., it should behave as if the field were not present, likely falling back to other cache control mechanisms present). </ins> 2.3.

Related discussion:
text: This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.