Draft: draft-ietf-webtrans-http2

Commentary: Chair : discussed during editors ' call , plan is to go with Martin 's simpler proposed encoding . We might want to discuss non - zero defaults later , but that 'll be its own separate issue . 
 The document currently does not specify what the initial flow control windows are , nor how to change those . We have two options : Add WT_SETTINGS capsule Put those into headers 
 Discussed in editor 's meeting , initial thinking is to put these values into the headers on the CONNECT message , rather than defining a new capsule or otherwise polluting HTTP/2 's settings 
 Is there any reason that you want to avoid settings ? The main thing that using settings would do is to provide the client with non - zero initial flow control limits on WT streams , so that it can send application data with zero latency . You ca n't get that without using settings . Functionally speaking , there is no real difference between a new capsule and a field , except that you can be a little more efficient with a capsule , modulo some issues regarding sequencing ( do you allow it to appear anywhere ? how do you manage changing values ? etc ... ) 
 If we 're talking about H2 - connection level settings , then those are scoped to the entire connection . Using those would bring us closer to how H3 behaves ( where connection - level stream configuration applies to WebTransport stream due to WT streams also being QUIC streams ) . On the other hand , we have designed WebTransport over HTTP/2 so that everything that happens within the CONNECT stream , so using headers / capsule instead of settings would be consistent with that . It would also mean you can transparently proxy WT - H2 to WT - H2 without parsing it ( I do realize we currently say that you 're not supposed to do that ) . Agreed . I have a mild preference for header fields since those are guaranteed to always arrive before any payload , making reasoning about their properties slightly easier . 
 The problem , as I see it , is that fields or capsules both lead to a situation where the client is unable to send any application data in its first flight ( that is , along with the CONNECT - wossname request ) . What I want to avoid is the case where clients decide to improve performance by remembering initial values . I 'm very much inclined to implement that caching , if only because it means that we can start using a session more quickly ( for anything other than 0 - RTT ) . Perhaps the right answer is that we need some sort of way to encapsulate origin - wide per - resource configuration ( that is , a baseline configuration that applies to all resources on the origin ) and - until then - we stick with populating each resource with fields . 
 Chair : discussed during editors ' call , see 
 Any reason why you did not do a single header field , like : Then at least the common repetitive stuff is n't repeated .
The initial flow control limit for unidirectional streams opened
by the recipient of this header field.  MUST be an Integer.
The initial flow control limit for the bidirectional streams
opened by the sender of this header field.  MUST be an Integer.
The initial flow control limit for the bidirectional streams
opened by the recipient of this header field.  MUST be an Integer.