Draft: draft-ietf-webtrans-http3

Commentary:   and maxdatagramframe_size TP 
 Interesting thought . One way to do that replaces the entire section with this : This is certainly more concise , although it does also remove some of the explanations that help people understand the various layers involved . Or perhaps we should include those same additional details but just turn those paragraphs into bullets ? 
 While technically true , I thought we 'd said that we wanted to require all the features all of the time , but agreed , let 's take that to an editorial issue if needed . 
 My point is that the server could support both regular HTTP and WebTransport . If a client comes in without webtransport settings and only sends GETs , that 's fine . If a client comes in with webtransport settings and makes a webtransport request , that 's fine . If a client comes in without webtransport settings and makes a webtransport request , that 's not fine . In that case the server needs to reject the webtransport request , not kill the connection . 
 Ah , that makes more sense , thank you 
 Per discussion at IETF 114 , we should explicitly require support for each layer of capabilities that are needed . There was also a discussion about whether or not we needed to require datagram support , since requiring capsules technically means that you could use a datagram capsule and implementations may exist that do not want to have datagram support at all . Documenting some of that discussion in replies to this issue , as well . 
 Specific to datagrams and capsules : WT supported means that capsule protocol is supported , thus you must always support capsules . Proposal : You need to have datagrams in order to do WT over HTTP/3 Adding additional signaling to negotiate datagram support introduces a lot of additional complexity and different configurations that may harm interoperability . Dropping a datagram is about as easy as doing any other error path HTTP Datagrams must already be supported in the receive direction for capsules ( and you need capsules for WT ) either way Intermediaries will need to be able to either translate for upstream or ensure that upstream can provide an equivalent feature set More generally : We want to explicitly call out dependencies / prerequisites so that we do n't need to teach layers about other layers . For example , WT being supported does n't mean that the layers that implement capsules , H3 datagrams , or QUIC datagrams should have any idea about the existence of WebTransport 
 Discussed at IETF 115 , consensus in room to require all the relevant settings and transport parameters to be sent individually 
 So we need : HTTP Setting : SETTINGSH3DATAGRAM ( 0x33 ) with a value of 1 for HTTP datagrams QUIC TP : maxdatagramframesize with a value greater than 0 for QUIC datagrams  protocol support is implicit in the upgrade token , as explicitly called out by RFC 9297 or we can require to be sent on every extended connect request as well . to be to the existing HTTP Setting : SETTINGSENABLEWEBTRANSPORT = 1 HTTP Setting : SETTINGSWEBTRANSPORTMAXSESSIONS 0 ( although we may be removing SETTINGSENABLEWEBTRANSPORT ) 
 SGTM I think we can skip mentioning Capsule - Protocol to match CONNECT - UDP 
 Would this be easier to process as a list rather than multiple separate requirements?The list text in that comment is n't correct - the server should n't close the connection because it 's legal for the client to not support datagrams if it only sends GETs and POSTs . However , the text in this PR is correct . I propose we land the PR as - is and can make editorial changes later .
Because WebTransport over HTTP/3 requires support for HTTP/3
datagrams and the Capsule Protocol, both the client and the server
MUST indicate support for HTTP/3 datagrams by sending a
SETTINGS_H3_DATAGRAM value set to 1 in their SETTINGS frame (see
Section 2.1.1 of HTTP-DATAGRAM).
WebTransport over HTTP/3 also requires support for QUIC datagrams.
To indicate support, both the client and the server MUST send a
max_datagram_frame_size transport parameter with a value greater than
0 (see Section 3 of QUIC-DATAGRAM).