Draft: draft-ietf-quic-http

Commentary: 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 : moment the server has 1 - RTT send - keys available ( i.e. , after   ) 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 : for the settings frame to arrive ( and therefore block , which is n't exactly elegant ) 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 ca n'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 .
Paragraph (version A):
For clients using a 1-RTT QUIC connection, the initial value of each
server setting is the default value.  When a 0-RTT QUIC connection is
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
stored settings until the current server settings are received.
Paragraph (version B):
For clients using a 1-RTT QUIC connection, the initial value of each
server setting is the default value.  When a 0-RTT QUIC connection is
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
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.
Paragraph (version A):
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
might be violated by the client with its 0-RTT data.
Paragraph (version B):
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
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.