Original text:
the response is produced, by enumerating the request header fields that it varies on, along with the values that are available for each. <del> Each "variant-item" indicates a request header field that carries a value that clients might proactively negotiate for; each parameter on it indicates a value for which there is an available representation on the origin server. </del>  So, given this example header field:

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:
the response is produced, by enumerating the request header fields that it varies on, along with the values that are available for each.  <ins> Variants 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 Variants header field. The Variants header field represents an ordered list of "variant- axes", each of which consists of a request header "field-name" string and a list of "available-value" strings.  Each inner-list in the Variants header field value is parsed into a variant-axis.  The first list-member of the inner-list is interpreted as the field-name, and the remaining list-members are the available-values.  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. Field-names in the Variants header field value MUST match the field- name production (Section 3.2 of RFC7230).  Clients receiving an invalid field-name MUST NOT match it to any content negotiating mechanism. </ins> So, given this example header field: