Original text:
gzip-compressed French representation. When more than one Variant-Key value is in a response, the first one <del> present MUST indicate the variant-key for the response it occurs within. 3.1. This algorithm generates a list of normalised strings from Variant- Key, suitable for comparison with values generated by cache. Given stored-headers (a set of headers from a stored response), a normalised list of variant-keys for that message can be generated by following this algorithm: Let variant-keys be an empty list. Let variant-key-header be a string, the result of selecting all field-values of stored-headers whose field-name is "Variant-Key" and joining them with a comma (","). </del>  <del> Let value-list be the result of splitting variant-key-header on commas (","). </del>  <del> For each value in value-list: </del>  <del> Remove all whitespace from value. </del>  <del> Append value to variant-keys. Return variant-keys. </del>  4. Caches that implement the Variants header field and the relevant <del> semantics of the field-name it contains can use that knowledge to </del>  either select an appropriate stored representation, or forward the request if no appropriate representation is stored.

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:
gzip-compressed French representation. When more than one Variant-Key value is in a response, the first one  <ins> present MUST correspond to the request that caused that response to be generated. </ins>  <ins> Parsing is strict.  For example: </ins>  <ins> is treated as if the Variant-Key header were completely absent, which will tend to disable caching for the representation that contains it. </ins>  <ins> Note that in </ins>  <ins> The whitespace after "gzip" in the first header field value is excluded by the token parsing algorithm, but the whitespace in the second header field value is included by the string parsing algorithm.  This will likely cause the second header field value to fail to match client requests. </ins> 4. Caches that implement the Variants header field and the relevant  <ins> semantics of the field-names it contains can use that knowledge to </ins> either select an appropriate stored representation, or forward the request if no appropriate representation is stored.