Original text:
being used, the initial value of each server setting is the value used in the previous session.  Clients MUST store the settings the server provided in the session being resumed and MUST comply with <del> stored settings until the current server settings are received. </del>  A server can remember the settings that it advertised, or store an integrity-protected copy of the values in the ticket and recover the A server MAY accept 0-RTT and subsequently provide different settings in its SETTINGS frame.  If 0-RTT data is accepted by the server, its SETTINGS frame MUST NOT reduce any limits or alter any values that <del> might be violated by the client with its 0-RTT data. </del>  7.2.6.

Reviewer comments:
My issue is the following: The current HTTP/3 specifications say that a SETTINGS frame must be sent as the first frame of the control stream directly following QUIC connection establishment. Depending on how connection establishment is defined, this could result in some awkward client-sided behavior. There are two ways to interpret connection establishment as far as I can tell: The moment the server has 1-RTT send-keys available (i.e., after Client Hello) On receipt of the client finished TLS packet In the first case, the server can specify its settings before the client makes its first request. In the second case however, the client can already send its first request before having received the server's settings. To handle this case, the specifications say the following: Now say for example that a client wants to use Firefox's prioritization scheme and connection establishment is defined in the second way (receipt of client finished packet). Ideally it would use placeholders to structure the dependency tree, but as it has not yet received a settings frame, it is not allowed to do so (default placeholder count is 0). This gives the client two options from what I can tell: Wait for the settings frame to arrive (and therefore block, which isn't exactly elegant) Use a fallback prioritization scheme and reprioritize requests later when the settings frame has been received and it allows the placeholders the client wants to use (which we'd also ideally like to avoid). As neither of these options are preferred, the importance of the definition of connection establishment is highlighted even more. My request is, if a clear answer has already been thought out, to add a more verbose description of what connection establishment actually means in this situation.
I agree that this is an unnecessary complexity, and I think might solve the issue.
The first is true -- the server SHOULD send its SETTINGS frame immediately. However, any packet can be delayed, so the client can't count on having seen SETTINGS prior to being able to send a request. This constrains the use of placeholders, header compression, extensions, etc. The current design permits the implementation to choose -- block on the SETTINGS frame (which used to be required) or send requests under the (very conservative) default constraints and do better once SETTINGS arrives. Our decision was to open up this flexibility of design rather than requiring either behavior. Do you have suggestions on how to make this clearer?
In my opinion, adding something like you just said to the specifications would be perfect. Given that section 7.2.5.2 already mentions default settings values, it might not be bad to just expand it there. For example: could be appended with something along the lines of: I think the most important part here is being a little more verbose about the edge case instead of just implying its existence by mentioning the default values for settings. If anyone has any other thoughts about it I'd love to hear them.

Revised text:
being used, the initial value of each server setting is the value used in the previous session.  Clients MUST store the settings the server provided in the session being resumed and MUST comply with  <ins> stored settings until the current server settings are received.  A client can use these initial values to send requests before the server's SETTINGS frame has arrived.  This removes the need for a client to wait for the SETTINGS frame before sending requests. </ins> A server can remember the settings that it advertised, or store an integrity-protected copy of the values in the ticket and recover the A server MAY accept 0-RTT and subsequently provide different settings in its SETTINGS frame.  If 0-RTT data is accepted by the server, its SETTINGS frame MUST NOT reduce any limits or alter any values that  <ins> might be violated by the client with its 0-RTT data.  The server MAY omit settings from its SETTINGS frame which are unchanged from the initial value. </ins> 7.2.6.