Original text:
3. <del> The Variant-Key HTTP response header field is used to indicate the values from the Variants header field that identify the representation it occurs within. Each member of the list contains a set of selected available-value(s) that identify this representation, in the same order as the variants listed in the Variants header field. Therefore, each member of Variant-Key MUST be the same length (in semicolon-separated members) as Variants, and each member's available-values MUST correspond in position to their companions in Variants. </del>  For example:

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:
3.  <ins> The Variant-Key HTTP response header field identifies a set of variants provided by the representation it occurs within.  A variant is identified by a selection of one available-value from each variant-axis from the Variants header field. Variant-Key is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be a list-of-lists (Section 3.3 of I-D.ietf-httpbis- header-structure) whose members are strings (Section 3.8 of I-D.ietf- httpbis-header-structure) or tokens (Section 3.9 of I-D.ietf-httpbis- header-structure).  Its ABNF is: If Structured Header parsing fails or a list-member has the wrong type, the client MUST treat the representation as having no Variant- Key header field. Each inner-list MUST have the same number of list-members as there are variant-axes in the representation's Variants header field.  If not, the client MUST treat the representation as having no Variant- Key header field. Each list-member is treated as identifying an available-value for the corresponding variant-axis' field-name.  Any list-member that is a token (Section 3.9 of I-D.ietf-httpbis-header-structure) is interpreted as a string containing the same characters.  These available-values do not need to explicitly appear in the Variants header field.  For example, Accept-Encoding defines an implicit "identity" available-value (content-encoding). </ins> For example: