Original text:
components MUST be negotiated before being used.  For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. <del> In this case, it could also be necessary to coordinate when the revised layout comes into effect. </del>  This document doesn't mandate a specific method for negotiating the use of an extension but notes that a setting (settings-parameters)

Reviewer comments:
Simply notes that coordination is hard in the face of SETTINGS, so it's likely to be better to replace than modify.
Resolution of was to have no design change, but consider a "here be dragons" warning in the extension section paralleling what was added to HTTP/3 in . (The reasons, and therefore the guidance, are different at the transport layer -- we can't directly steal the text.)
Unlike HTTP/2, HTTP/3 has no indication when the peer has received and processed SETTINGS. This means that any extension which redefines a basic protocol element (e.g. HEADERS uses something other than QPACK or uses a different static table; PRIORITY frames should be interpreted differently) has to define its own coordination mechanism -- and that coordination mechanism will be unwieldy (see ). would give the necessary ordering for server settings -- they are effective for all server data -- but would only make sense if one side considered the other's SETTINGS prior to sending its own. The server cannot do this in the current scheme or in for 1-RTT connections. Should we simply remove the misleading suggestions that elements of the mapping can be redefined, pointing people instead to creating replacement frames (HEADERS2, PRIORITYEX, etc.)? Or is the verbiage here that you're on your own to coordinate that switch sufficient hard-hat warning?
Thanks for creating this issue. I don't think using extension frames completely solves the problem because of the risks of changing the core behaviour so dramatically without endpoint coordination. For example, a client that sends requests only using HEADERS2 would need to wait for a HEADERS2 response before deciding that the extension is supported? That's a pretty big gamble to make. Given the challenge to design a solution and the reality that we don't need one right now (but that we are chartered to allow H2-like extension mechanisms) I'd be inclined to say remove the specific example and summarise that these components mean frames, unidirectional stream types, request/response message exchanges etc.
I think what a client would do is send HEADERS until it sees the SETTINGS frame and discovers it can use HEADERS2 from now on, including in 0-RTT in the future. No gamble involved, but the server has to continue to support the "old" elements as well.
Yes, that is how I would do it. The idea would be that once you advertise support for HEADERS2, you could receive one at any time, but you might still receive the old version for an indefinite period. You probably shouldn't even rely on seeing an ACK for the SETTINGS frame bits.
Your extension could define a frame that simply means, "I pinky swear I won't ever use the old frames again." But then you have all the same cross-stream coordination issues.

Revised text:
components MUST be negotiated before being used.  For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable.  <ins> Coordinating when such a revised layout comes into effect could prove complex.  As such, allocating new identifiers for new definitions of existing protocol elements is likely to be more effective. </ins> This document doesn't mandate a specific method for negotiating the use of an extension but notes that a setting (settings-parameters)