Original text:
delivery of Client Hints on subsequent requests to the server's origin (RFC6454).  When a client receives an HTTP response that contains Accept-CH- Lifetime header field, the field-value indicates that the Accept-CH preference SHOULD be persisted and bound to the origin, and be

Reviewer comments:
NAME - can you take a look?
Migrating .. Julian:
NAME NAME per URL, how about... Does that make sense? Would appreciate your guidance on this one :)
I'm starting to wonder if Client Hints should adopt Structured Headers to avoid having to deal with these sorts of questions. Ilya, WDYT?
NAME that would hit a major reset on all existing CH implementations and set us back another couple years, I don't think this is the right call for CH. /cc NAME Surely CH is not the first instance where we had to spell out behavior for selecting one out of N header values? That said, if we don't have established verbiage for this, I'm happy to just make up some language ourselves to clarify how it should behave.. what we're aiming for ain't rocket science. :)
I wouldn't want to set CH back that much (although it is lingering on :). I only mention it because all of the defined syntax seems like it would easily fit into SH, and Chrome already has a good start on a SH parser, thanks to NAME work on signed exchanges, etc.
As an aside, the same clarification should also apply to response headers. Currently Chrome treats multiple responses headers as an error and ignores both.
NAME my preference is to get this over the finish line without introducing dependency on SH. For one, we're also relying on Feature-Policy for delegation and we decided against SH there. WDYT of suggested text in URL — warmer? NAME ack.
NAME I hear you. My thinking is: We've already waited a good while for CH, and it's not clear that it's really really done yet (I suspect we have at least one more round of doc review). People are already using CH as a framework for new hints, so getting SH in would be best now if it's going to get in. If CH are going to be commonly sent, having well-defined parsing behaviour and the possibility of better serialisations (which SH gives us) is very attractive. To be clear -- this is me as me, not me as chair.
NAME - could you clarify what you mean by CH adopting SH? Do you mean that the / headers would be defined as /? Or that they'd be define as with extended processing model (which guarantees that the last item in the list "wins")? Or something else altogether?
Both and could be s. would be a of s. Both and would be s. would be a . I'm not really sure why its current ABNF is a list. NAME Considering that parsing and serialisation algorithms for these haven't been defined yet at all, I don't think it would take a lot of work (and would be happy to do a PR).
Good catch, I think that's an oversight and we can fix that. Stepping back, my preference is (still) to proceed at this stage without introducing dependency on SH. First off, introducing SH does not address the issue we're actually trying to solve in this bug. Second, it adds another significant dependency to CH adoption that I would like to avoid at this stage, as it's yet another reason for a browser vendor to drag their feet and delay integrating support for SH. To get CH over the last call barrier, I believe we have two outstanding tasks: Clarify Accept-CH-Lifetime definition, per above. Provide some minimum guidance on how to deal with aggregated values — see URL I don't think we'll land on perfect text for (2), but this is not a unique or new gap vs other and existing specs, and I don't think we should block on this. NAME does this sound reasonable?
friendly bump :-) NAME NAME PTAL, any thoughts or guidance on the above text?
The issue is that it's defined to only have one value. I think you'd need to say something like: Or, to really define it, define an algorithm.
This was discussed at the HTTPWG meeting today and it was decided to go ahead with Structured Headers!
Based on group discussion at IETF, everyone is on board.

Revised text:
delivery of Client Hints on subsequent requests to the server's origin (RFC6454). <ins> Accept-CH-Lifetime is a Structured Header I-D.ietf-httpbis-header- structure.  Its value MUST be sh-integer (Section 3.4 of I-D.ietf- httpbis-header-structure).  Its ABNF is: </ins> When a client receives an HTTP response that contains Accept-CH- Lifetime header field, the field-value indicates that the Accept-CH preference SHOULD be persisted and bound to the origin, and be