Original text:
Let sorted-variants be an empty list. If the freshest member of stored-responses (as per RFC7234, <del> Section 4.2) has one or more "Variants" header field(s): </del>  <del> Select one member of stored-responses and let variants-header be its "Variants" header field-value(s).  This SHOULD be the most recent response, but MAY be from an older one as long as it is still fresh. </del>  <del> For each variant in variants-header, parsed according to the ABNF: </del>  <del> If variant's field-name corresponds to the request header field identified by a content negotiation mechanism that the implementation supports: </del>  Let request-value be the field-value associated with field-name in incoming-request (after being combined as allowed by Section 3.2.2 of RFC7230), or null if field- name is not in incoming-request. <del> Let available-values be a list containing all available- value for variant. </del> Let sorted-values be the result of running the algorithm defined by the content negotiation mechanism with <del> request-value and available-values. </del>  Append sorted-values to sorted-variants. At this point, sorted-variants will be a list of lists, each <del> member of the top-level list corresponding to a variant-item in </del>  the Variants header field-value, containing zero or more items indicating available-values that are acceptable to the client, in order of preference, greatest to least. Return result of running Compute Possible Keys (find) on sorted- <del> variants, an empty string and an empty list. </del>  <del> This returns a list of strings suitable for comparing to normalised Variant-Keys (gen-variant-key) that represent possible responses on the server that can be used to satisfy the request, in preference </del>  order, provided that their secondary cache key (after removing the headers covered by Variants) matches. check_vary illustrates one way to do this.

Reviewer comments:
I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?

Revised text:
Let sorted-variants be an empty list. If the freshest member of stored-responses (as per RFC7234,  <ins> Section 4.2) has one or more "Variants" header field(s) that successfully parse according to variants: </ins>  <ins> Select one member of stored-responses with a "Variants" header field-value(s) that successfully parses according to variants and let variants-header be this parsed value.  This SHOULD be the most recent response, but MAY be from an older one as long as it is still fresh. </ins>  <ins> For each variant-axis in variants-header: </ins>  <ins> If variant-axis' field-name corresponds to the request header field identified by a content negotiation mechanism that the implementation supports: </ins> Let request-value be the field-value associated with field-name in incoming-request (after being combined as allowed by Section 3.2.2 of RFC7230), or null if field- name is not in incoming-request.  Let sorted-values be the result of running the algorithm defined by the content negotiation mechanism with  <ins> request-value and variant-axis' available-values. </ins> Append sorted-values to sorted-variants. At this point, sorted-variants will be a list of lists, each  <ins> member of the top-level list corresponding to a variant-axis in </ins> the Variants header field-value, containing zero or more items indicating available-values that are acceptable to the client, in order of preference, greatest to least. Return result of running Compute Possible Keys (find) on sorted-  <ins> variants, an empty list and an empty list. </ins>  <ins> This returns a list of lists of strings suitable for comparing to the parsed Variant-Keys (variant-key) that represent possible responses on the server that can be used to satisfy the request, in preference </ins> order, provided that their secondary cache key (after removing the headers covered by Variants) matches. check_vary illustrates one way to do this.