2. <del> This section describes the components in a satellite system based on SATCOM systems dedicated to broadband Internet access that follows the DVB standards.  A high-level description of a multi-gateway satellite network is provided.  There are multiple SATCOM systems, such as those dedicated to broadcasting TV or to IoT applications: depending on the purpose of the SATCOM system, ground segments are specific.  In this context, the increase of the available capacity that is carried out to end users and reliability requirements lead to multiple gateways for one unique satellite platform. </del>  In this context, fig:sat_gateway shows an example of a multi-gateway satellite system.  In a multi-gateway system, some elements may be centralized and/or gathered: the relevance of one approach compared to another depends on the deployment scenario.  More information on these discussions and a generic SATCOM ground segment architecture <del> for a bi-directional Internet access can be found in SAT2017. </del>  Some functional blocks aggregate the traffic of multiple users. <del> Coding techniques could be applied on both single and aggregated traffic. </del> 3.

"This section describes the components in satellite system that layson SATCOM systems dedicated to broadband Internet access that follows the DVB standards" -- This section describes the components of a satellite system that follows the ETSI DVB standards to provide broadband internet access. (Actually, DVB-S standards). Following the DVB standards has effects on draft scope and terminology. Are you sure you want to do that? The current approach to DVB-S seems to be to pick and choose whatever is convenient to the argument. A high-level description of a multi-gateway satellite network is provided. "a bi-directional' - elide a, elide - Fig 1 doesn't resemble the multi-gateway DVB satellite systems that I have worked on. Indoor and outdoor unit typically refers to the customer satellite terminal pieces as well, not jut a piece of the gateway. (Indoor - network to/from intermediate frequency IF. Outdoor: IF to/from RF) The satellite link appears to be in the wrong place, or the terminal needs breaking down further. And there's no mention of FECFRAME? PLFRAME is the structure, the data gets turned into FECFRAME. But that has "FEC" in it and this draft aims to downplay FEC... awks. Encaps like GSE or MPE have been skipped, but that's really just added flavour.
Vincent : First sentence is not very clear (structure (that ... that...), missing "a" in "in statellite system that lays...", etc. Last sentence "Coding schemes could be applied on both single and aggregated traffic." deserves to be detailed. Will it be discussed later on in this document?
We have proposed some changes in PR . On the comment on following DVB standards : These documents let us have a common view of the different components of a SATCOM system. If you have any public pointer with other naming, we would be happy to have it to see if there are main issues with the actual naming in the document. On the comment on Fig 1, indoor and outdoor unit: We think we have clarified the usage of FEC in the document. The notion of physical gateway is not actually standardised, but the proposed figure let us explain the different use-cases. This is the main rational of this figure.

2.  <ins> This section describes a satellite system that follows the ETSI DVB standards to provide broadband Internet access.  A high-level description of a multi-gateway satellite network is provided.  There are multiple SATCOM systems, such as those dedicated to broadcasting TV or to IoT applications: depending on the purpose of the SATCOM system, ground segments are specific.  In this context, the increase of the available capacity that is carried out to end users and reliability requirements lead to multiple gateways for one unique satellite platform. </ins> In this context, fig:sat_gateway shows an example of a multi-gateway satellite system.  In a multi-gateway system, some elements may be centralized and/or gathered: the relevance of one approach compared to another depends on the deployment scenario.  More information on these discussions and a generic SATCOM ground segment architecture  <ins> for bidirectional Internet access can be found in SAT2017. </ins> Some functional blocks aggregate the traffic of multiple users.  3.


deployment in satellite systems. X1 embodies the source coding techniques that could be used at <del> application level for instance within QUIC or other video streaming applications.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </del>  X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited).

this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR

deployment in satellite systems. X1 embodies the source coding techniques that could be used at  <ins> application level for instance within QUIC.  This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions. </ins> X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited).


Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. <del> FEC (also called Application-Level FEC) operate above the network layer. </del>  This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding

Q (Dave Oran): in or above network layer (above means no re-encoding in the router)? A: both - and the document is clear about it - no layer 2 coding. Q (Stew Card): what are the "C" is the architecture picture? A: this is where we could put the coding.
Done with PR and

Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document.  <ins> FEC (also called Application-Level FEC) operate in and above the network layer. </ins> This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding


1.  Guaranteeing both physical-layer robustness and efficient usage of the radio resource has been in the core design of SATellite COMmunication (SATCOM) systems.  The trade-off often resided in how developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems. <del> The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: ACM : Adaptive Coding and Modulation; BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is encapsulated with a Generic Stream Encapsulation (GSE) mechanism, (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; CPE: Customer Premises Equipment; COM: COMmunication; DSL: Digital Subscriber Line; DTN: Delay/Disruption Tolerant Network; DVB: Digital Video Broadcasting; E2E: End-to-end; ETSI: European Telecommunications Standards Institute; FEC: Forward Error Correction; FLUTE: File Delivery over Unidirectional Transport; IntraF: Intra-Flow Coding; InterF: Inter-Flow Coding; IoT: Internet of Things; LTE: Long Term Evolution; MPC: Multi-Path Coding; NC: Network Coding; NFV: Network Function Virtualization; NORM: NACK-Oriented Reliable Multicast; PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for satellite communications include compression, caching and TCP acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME with additional information (e.g., related to synchronization); QEF: Quasi-Error-Free; QoE: Quality-of-Experience; QoS: Quality-of-Service; SAT: SATellite; SATCOM: generic term related to all kind of SATellite COMmunication systems; SPC: Single-Path Coding; VNF: Virtual Network Function. This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. </del> 2. This section describes a satellite system that follows the ETSI DVB 6. <del> This memo includes no request to IANA. </del>  7.  Security considerations are inherent to any access network, and in particular SATCOM systems.  The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant

Shouldn't the 'This document is a product of' para be far earlier in the document? Should mention be made of a glossary at end, rather than putting the glossary at the front?
In PR : we have moved the glossary to the bottom of the document and moved the "This document is a product of" at the beginning of the introduction.

1. <ins> This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard.  A glossary is proposed in sec:glossary. </ins> Guaranteeing both physical-layer robustness and efficient usage of the radio resource has been in the core design of SATellite COMmunication (SATCOM) systems.  The trade-off often resided in how developments.  In this context, this document aims at identifying opportunities for further usage of coding in these systems.  2. This section describes a satellite system that follows the ETSI DVB 6.  <ins> The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: ACM : Adaptive Coding and Modulation; BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is encapsulated with a Generic Stream Encapsulation (GSE) mechanism, (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs contain information related to how they have to be modulated (4) BBFRAMEs are forwarded to the physical-layer; CPE: Customer Premises Equipment; COM: COMmunication; DSL: Digital Subscriber Line; DTN: Delay/Disruption Tolerant Network; DVB: Digital Video Broadcasting; E2E: End-to-end; ETSI: European Telecommunications Standards Institute; FEC: Forward Error Correction; FLUTE: File Delivery over Unidirectional Transport; IntraF: Intra-Flow Coding; InterF: Inter-Flow Coding; IoT: Internet of Things; LTE: Long Term Evolution; MPC: Multi-Path Coding; NC: Network Coding; NFV: Network Function Virtualization; NORM: NACK-Oriented Reliable Multicast; PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for satellite communications include compression, caching and TCP acceleration; PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME with additional information (e.g., related to synchronization); QEF: Quasi-Error-Free; QoE: Quality-of-Experience; QoS: Quality-of-Service; SAT: SATellite; SATCOM: generic term related to all kind of SATellite COMmunication systems; SPC: Single-Path Coding; VNF: Virtual Network Function. </ins> 7. <ins> This memo includes no request to IANA. 8. </ins> Security considerations are inherent to any access network, and in particular SATCOM systems.  The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant


document RFC8406: Channel and link codings are gathered in the PHY layer coding and <del> are out of the scope of this document. </del>  FEC (also called Application-Level FEC) operates in and above the network layer.

I'm puzzled as to how this document claims that channel and link codings are out of scope - and then talks about channel mode, dealing with varying channel conditions (yet without using channel codings), etc. They're stated as out of scope...
If the intent is treating the overall end-to-end path as some sort of virtual 'channel' that coding packets are applied to, this needs to be said explicitly upfront. If 'channel' means more than one concatenated physical path here, this needs to be said. Unless your audience is only network coding people... the title should likely be 'network coding applicability to satellite-based scenarios' or similar, too. Needs to be really specific for clarity.
In PR , we have changed: "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document." by "Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document. It focuses on situations where coding is not widely deployed in current SATCOM systems." For the comment on the end-to-end path, the notion of virtual 'channel' depends on the use-case and coding is not applied at the same level. For the title, we have moved from "Network coding and satellites" to "Coding techniques for satellite systems" from version 04 and 05 of the document to be more generic. I guess we should not go back to the "network coding"-like title.

document RFC8406: Channel and link codings are gathered in the PHY layer coding and  <ins> are out of the scope of this document.  It focuses on situations where coding is not widely deployed in current SATCOM systems. </ins> FEC (also called Application-Level FEC) operates in and above the network layer.


4.1. <del> SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward </del>  TCP packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., <del> the quickly varying channel conditions use-case. </del>  4.3.

section 4.1 - PEP is Enhancing, not Enhancement. PEPs usually split... section 4.2 - quickly varying channel conditions - if on the satellite link (where discussing channel conditions is out of scope?) that's what ACM, which is defined in the glossary, does -- and where network coding does not do as well. ASMS - spell out the conference name. No need to abbreviate journal names - this isn't an academic paper with a page limit. Do provide document object idenitifiers (DOIs) of papers where they exist
Thanks for the nits on the PEP. For the comment on ACM, we have updated the text (PR ) : "This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case where ACM may not be reacting quickly enough." We have updated the conference in PR and PR

4.1.  <ins> SATCOM systems typically feature Performance Enhancing Proxy (PEP) RFC3135.  PEPs usually split TCP end-to-end connections and forward </ins> TCP packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g.,  <ins> the quickly varying channel conditions use-case where ACM may not be reacting quickly enough. </ins> 4.3.


1. HTTP/2 RFC7540 transports HTTP messages via a framing layer that <del> includes many technologies and optimizations designed to make communication more efficient between clients and servers.  These include multiplexing of multiple streams on a single underlying transport connection, flow control, stream dependencies and priorities, header compression, and exchange of configuration information between endpoints. </del>  Currently, the only mechanism in HTTP/2 for server to client communication is server push.  That is, servers can initiate unidirectional push promised streams to clients, but clients cannot <del> respond to them and either accept or discard them silently. </del>  Additionally, intermediaries along the path may have different server push policies and may not forward push promised streams to the downstream client.  This best effort mechanism is not sufficient to <del> reliably deliver content from servers to clients, limiting additional use-cases such as sending messages and notifications from servers to clients immediately when they become available. </del>  Several techniques have been developed to workaround these limitations: long polling RFC6202, WebSocket RFC8441, and tunneling using the CONNECT method.  All of these approaches layer an application protocol on top of HTTP/2, using HTTP/2 streams as transport connections.  This layering defeats the optimizations <del> provided by HTTP/2.  For example, multiplexing multiple parallel interactions onto one HTTP/2 stream reintroduces head of line blocking.  Also, application metadata is encapsulated into DATA frames, rather than HEADERS frames, making header compression impossible.  Further, user data is framed multiple times at different protocol layers, which offsets the wire efficiency of HTTP/2 binary framing. </del>  This document defines Http2Transport, a mechanism for multiplexing <del> non-HTTP data with HTTP/2 in a manner that conforms with the WebTransport protocol framework I-D.vvv-webtransport-overview.  Using the mechanism described, multiple Http2Transport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/2 connection. </del>  Section 8.3 of RFC7540 defines the HTTP CONNECT method for HTTP/2, <del> which converts a HTTP/2 stream into a tunnel for arbitrary data. </del>  RFC8441 describes the use of the extended CONNECT method to negotiate the use of the WebSocket Protocol RFC6455 on an HTTP/2 stream. Http2Transport uses the extended CONNECT handshake to allow <del> WebTransport endpoints to multiplex arbitrary data on HTTP/2 streams. </del>  <del> In this draft, a new HTTP/2 frame is introduced which has the routing properties of a PUSH_PROMISE frame and the bi-directionality of a HEADERS frame.  The extension provides several benefits: </del>  <del> After a HTTP/2 connection is established, a server can initiate streams to the client at any time, and the client can respond to the incoming streams accordingly.  That is, the communication over HTTP/2 is bidirectional and symmetric. </del>  <del> All of the HTTP/2 technologies and optimizations still apply. Intermediaries also have all the necessary metadata to properly handle the communication between the client and the server. </del>  <del> Clients are able to group streams together for routing purposes, such that each individual stream group can be used for a different service, within the same HTTP/2 connection. </del>  2. 3.  Http2Transport servers are identified by a pair of authority value and path value (defined in RFC3986 Sections 3.2 and 3.3 <del> respectively).  Http2Transport uses the extended CONNECT handshake to negotiate a new upgrade token, "webtransport".  It also defines an HTTP/2 extension that introduces a new frame, "WTHEADERS", which allows for bidirectional communication between the WebTransport server and the client, and it introduces a new HTTP/2 SETTINGS parameter to negotiate the use of the "WTHEADERS" frame. </del>  <del> 3.1. </del>  <del> Use of the extended CONNECT method extension defined in RFC8441 requires the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter to be received by a client prior to its use.  An endpoint that supports receiving the extended CONNECT method SHOULD send this setting with a value of 1. </del>  The extended CONNECT method extension uses the ":protocol" psuedo- header field to negotiate the protocol that will be used on a given This token is used in the ":protocol" psuedo-header field to indicate that the endpoint wishes to use the WebTransport protocol on the new <del> stream.  If successful, the resulting stream established via the extended CONNECT handshake is referred to as a WebTransport Connect Stream, or simply a Connect Stream. </del>  <del> 3.2. </del>  <del> A new HTTP/2 frame called "WTHEADERS" is introduced for establishing streams in a bidirectional manner.  A stream opened by a "WTHEADERS" frame is referred to as a WebTransport Stream, and it MAY be continued by CONTINUATION and DATA frames.  WebTransport Streams can be initiated by either clients or servers via a "WTHEADERS" frame that refers to the corresponding client-initiated extended CONNECT stream on which the WebTransport protocol was negotiated. </del>  The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2. closed (remote) stream state.  This allows WebTransport Streams to participate in header compression and flow control. <del> 3.3. </del>  As described in Section 5.5 of RFC7540, SETTINGS parameters allow endpoints to negotiate use of protocol extensions that would An endpoint that supports receiving the "WTHEADERS" as part of the WebTransport protocol SHOULD send this setting with a value of 1. <del> 3.4. </del>  An endpoint that wishes to establish a WebTransport session over an HTTP/2 stream follows the extended CONNECT handshake procedure HTTP/2 stream is considered to be that of the WebTransport protocol and follows the semantics defined by that protocol. <del> 3.5. </del>  An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the Section 10, and Section 10.5.2 especially, apply to this use of the CONNECT method. <del> Http2Transport requires explicit opt-in through the use of a HTTP/2 </del>  SETTINGS parameter, avoiding potential protocol confusion attacks by ensuring the HTTP/2 server explicitly supports the WebTransport protocol.  It also requires the use of the Origin header, providing This document adds an entry to the "HTTP/2 Frame Type" registry, the "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry, all <del> defined in RFC7540.  It also registers a HTTP upgrade token in the </del>  registry established by RFC7230. 6.1.

Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME

1. HTTP/2 RFC7540 transports HTTP messages via a framing layer that  <ins> includes many optimizations designed to make communication more efficient between clients and servers.  These include multiplexing of multiple streams on a single underlying transport connection, flow control, priorities, header compression, and exchange of configuration information between endpoints. </ins> Currently, the only mechanism in HTTP/2 for server to client communication is server push.  That is, servers can initiate unidirectional push promised streams to clients, but clients cannot  <ins> respond to them; they can only accept them or discard them. </ins> Additionally, intermediaries along the path may have different server push policies and may not forward push promised streams to the downstream client.  This best effort mechanism is not sufficient to  <ins> reliably deliver messages from servers to clients, limiting server to client use-cases such as chat messages or notifications. </ins> Several techniques have been developed to workaround these limitations: long polling RFC6202, WebSocket RFC8441, and tunneling using the CONNECT method.  All of these approaches layer an application protocol on top of HTTP/2, using HTTP/2 streams as transport connections.  This layering defeats the optimizations  <ins> provided by HTTP/2.  For example, application metadata is encapsulated in DATA frames rather than HEADERS frames, bypassing the advantages of HPACK header compression.  Further, application data might be framed multiple times at different protocol layers, reducing the wire efficiency of the protocol. </ins> This document defines Http2Transport, a mechanism for multiplexing  <ins> non-request/response streams with HTTP/2 in a manner that conforms with the WebTransport protocol framework I-D.vvv-webtransport- overview.  Using the mechanism described, multiple Http2Transport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/2 connection. </ins> Section 8.3 of RFC7540 defines the HTTP CONNECT method for HTTP/2,  <ins> which converts an HTTP/2 stream into a tunnel for arbitrary data. </ins> RFC8441 describes the use of the extended CONNECT method to negotiate the use of the WebSocket Protocol RFC6455 on an HTTP/2 stream. Http2Transport uses the extended CONNECT handshake to allow  <ins> WebTransport endpoints to multiplex arbitrary data streams on HTTP/2 connections. </ins>  <ins> In this draft, a new HTTP/2 frame is introduced which carries structured metadata like the HEADERS and PUSH_PROMISE frames, but without the constraints of the request/response state machine and semantics. </ins>  <ins> The WebTransport over HTTP/2 extension: </ins>  <ins> Enables bidirectional and symmetric communication over HTTP/2. After a WebTransport session is established, a server can initiate a WebTransport stream to the client at any time, and the client can respond to server-initiated streams. </ins>  <ins> Allows WebTransport streams to take advantage of HTTP/2 features such as header compression, prioritization and flow-control. Provides a mechanism for intermediaries to route server initiated messages to the correct client. Allows clients and servers to group streams and route them together. </ins> 2. 3. <ins> 3.1. After negotiating the use of this extension, clients initiate one or more WebTransport Connect streams to a Http2Transport Server. </ins> Http2Transport servers are identified by a pair of authority value and path value (defined in RFC3986 Sections 3.2 and 3.3  <ins> respectively).  The client uses the extended CONNECT method with a :protocol token "webtransport" to establish a WebTransport Connect Stream.  This stream is only used to establish a WebTransport session and is not intended for data exchange. </ins>  <ins> 3.2. Following the establishment of a WebTransport Connect stream, either the client or the server can initiate a WebTransport Stream by sending the "WTHEADERS" frame.  This frame references an open WebTransport Connect stream, which is used by any intermediaries to correctly forward the stream to the destination endpoint.  The only frames allowed on WebTransport Streams are WTHEADERS, CONTINUATION, DATA and any negotiated extension frames. 3.3. Clients negotiate the use of WebTransport ove HTTP/2 using both the SETTINGS frame and one or more extended CONNECT requests as defined in RFC8441. </ins>  <ins> Use of the extended CONNECT method extension requires the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter to be received by a client prior to its use.  An endpoint that supports receiving the extended CONNECT method SHOULD send this setting with a value of 1. </ins> The extended CONNECT method extension uses the ":protocol" psuedo- header field to negotiate the protocol that will be used on a given This token is used in the ":protocol" psuedo-header field to indicate that the endpoint wishes to use the WebTransport protocol on the new  <ins> stream. </ins>  <ins> 3.4. </ins>  <ins> Clients or servers use a WTHEADERS frame to initate a new WebTransport Stream. </ins> The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2. closed (remote) stream state.  This allows WebTransport Streams to participate in header compression and flow control.  <ins> 3.5. </ins> As described in Section 5.5 of RFC7540, SETTINGS parameters allow endpoints to negotiate use of protocol extensions that would An endpoint that supports receiving the "WTHEADERS" as part of the WebTransport protocol SHOULD send this setting with a value of 1.  <ins> 3.6. </ins> An endpoint that wishes to establish a WebTransport session over an HTTP/2 stream follows the extended CONNECT handshake procedure HTTP/2 stream is considered to be that of the WebTransport protocol and follows the semantics defined by that protocol.  <ins> 3.7. </ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the Section 10, and Section 10.5.2 especially, apply to this use of the CONNECT method.  <ins> Http2Transport requires explicit opt-in through the use of an HTTP/2 </ins> SETTINGS parameter, avoiding potential protocol confusion attacks by ensuring the HTTP/2 server explicitly supports the WebTransport protocol.  It also requires the use of the Origin header, providing This document adds an entry to the "HTTP/2 Frame Type" registry, the "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry, all  <ins> defined in RFC7540.  It also registers an HTTP upgrade token in the </ins> registry established by RFC7230. 6.1.


5.  WebTransport Streams established by the CONNECT handshake and the WTHEADERS frame are expected to be protected with a TLS connection. They inherit the security properties of this cryptographic context, share of controlled resources, both when sending data and opening new streams. <del> 6. </del>  This document adds an entry to the "HTTP/2 Frame Type" registry, the "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry, all defined in RFC7540.  It also registers an HTTP upgrade token in the registry established by RFC7230. <del> 6.1. </del>  The following entry is added to the "HTTP/2 Frame Type" registry established by Section 11.2 of RFC7540. _RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.2. </del>  The following entry is added to the "HTTP/2 Settings" registry that was established by Section 11.3 of RFC7540. _RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.3. </del>  The following entries are added to the "HTTP/2 Error Code" registry that was established by Section 11.2 of RFC7540. _RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.4. </del>  The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230. _RFC Editor: Please fill in this value with the RFC number for this document_ and <del> 7.  References </del>  <del> 7.1.  URIs </del>  [1] https://www.iana.org/assignments/http-upgrade-tokens/

Add brief section describing Http2Transport's stance on the properties enumerated in the WebTransport Overview. We can move this around later as necessary, but wanted to get the text in to document which optional properties are supported and which are not.
From the : We should enumerate the position that Http2Transport takes on each of these items. Specifically: No stream independenceNo partial reliabilityYes pooling supportNo connection mobility

5. <ins> The WebTransport framework I-D.vvv-webtransport-overview defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols.  Below are details about support in Http2Transport for those properties. Http2Transport does not support stream independence, as HTTP/2 inherently has head of line blocking. Http2Transport does not support partial reliability, as HTTP/2 retransmits any lost data.  This means that any datagrams sent via Http2Transport will be retransmitted regardless of the preference of the application. Http2Transport supports pooling, as multiple transports using Http2Transport may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context. Http2Transport does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP RFC7540, is used underneath HTTP/2 and TLS.  Without such support, Http2Transport connections cannot survive network transitions. 6. </ins> WebTransport Streams established by the CONNECT handshake and the WTHEADERS frame are expected to be protected with a TLS connection. They inherit the security properties of this cryptographic context, share of controlled resources, both when sending data and opening new streams.  <ins> 7. </ins> This document adds an entry to the "HTTP/2 Frame Type" registry, the "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry, all defined in RFC7540.  It also registers an HTTP upgrade token in the registry established by RFC7230.  <ins> 7.1. </ins> The following entry is added to the "HTTP/2 Frame Type" registry established by Section 11.2 of RFC7540. _RFC Editor: Please fill in this value with the RFC number for this document_  <ins> 7.2. </ins> The following entry is added to the "HTTP/2 Settings" registry that was established by Section 11.3 of RFC7540. _RFC Editor: Please fill in this value with the RFC number for this document_  <ins> 7.3. </ins> The following entries are added to the "HTTP/2 Error Code" registry that was established by Section 11.2 of RFC7540. _RFC Editor: Please fill in this value with the RFC number for this document_  <ins> 7.4. </ins> The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230. _RFC Editor: Please fill in this value with the RFC number for this document_ and  <ins> 8.  References </ins>  <ins> 8.1.  URIs </ins> [1] https://www.iana.org/assignments/http-upgrade-tokens/


The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2.  The WTHEADERS frame has one extra field, Connect Stream ID. WTHEADERS frames can be sent on a stream in the "idle", "open", or "half-closed (remote)" state, see stream-states.

As in the , We should document how we provide a unidirectional stream, likely by adding that as a parameter to the Connect stream.
Looking good! Few minor formatting nits, but nothing major.

The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2. <ins> The WTHEADERS frame has an additional flag, Unidirectional (0x40). When this flag is present, the stream starts in a half-closed state. The sending endpoint stream state is "half-closed (remote)" and the receiving endpoint state is "half-closed (local)". </ins> The WTHEADERS frame has one extra field, Connect Stream ID. WTHEADERS frames can be sent on a stream in the "idle", "open", or "half-closed (remote)" state, see stream-states.


4.2.  A new HTTP/2 frame called WT_DATAGRAM is introduced for either endpoint to transmit a datagram.  WT_DATAGRAM frames are sent with Stream Identifier 0. This document  The "WT_DATAGRAM" frame allows HTTP/2 client and server to exchange datagrams used by WebTransport:

Thanks for the review Martin. I suppose the higher fidelity version of STOPSENDING would not change the state of the stream at all, but induce the peer to send a RSTSTREAM as QUIC does. Maybe that is better.
Actually, there is worse: when I send STOP_SENDING, I no longer know when the peer has received and acted on that without an explicit stream termination signal, so I can't transition the stream to a closed state.
Wait, how is this different than QUIC? You can't close a bidirectional stream until the peer sends you a FIN or RST.
Right; I was reading your description of STOPSENDING as changing stream state, either at the point that it was sent or received. In that case, if a stream is "open", the sender of STOPSENDING might believe that all it needs to do is send RESETSTREAM to close the stream completely. If it does so, the peer will receive those frames and then both peers will believe the stream to be closed. But the sender of STOPSENDING has no way to distinguish between that set of circumstances and one where the peer takes an arbitrary amount of time to process the frames. The receiver of STOP_SENDING might just keep sending data indefinitely. How does the receiver of those frames know when the other side has truly stopped? You might say "too bad". After all, the only thing you need to do is keep counting against connection-level flow control, but it makes the "closed" state that much harder to manage.
As written, STOPSENDING does change stream state, which would allow the sender to move to closed unilaterally (for example, send WTRSTSTREAM and WTSTOPSENDING together). DATA frames may trickle in after that for the closed stream, you just keep handling them for connection flow control -- this is the same as RSTSTREAM in vanilla H2. If we make it like QUIC instead, where STOPSENDING does not affect state, the sender of the STOPSENDING has to wait for WTRSTSTREAM or a FIN to move to closed. So I think either model is fine and I don't have a stylistic preference. I'm wondering if it has an effect on the stream limit accounting, but I don't think it does? The H2 model frees the streams 1/2 RTT faster.
Ugh, I should know this stuff better, I only recently rewrote the closing bit in h2 to deal with this problem. Of course. It's bad, but no worse than status quo. Thanks for correcting me. (Full transparency: I think that the QUIC stream model is so much better than h2 that I can no longer stomach these minor infidelities in h2. This PR does manage to balance the need to provide API consistency across versions without fixing/changing h2's problems. I'm sure I'll manage to swallow my distaste eventually if we go this way.)
Heh. Since this is merging an H3 feature into H2 I feel like we could pick either model and still claim to be consistent. For now, I'll leave this H2 style.
QUIC and HTTP/3 support resetting only half of a bidirectional stream. If WebTransport requires this functionality, then this draft would need additional frames to convey those signals (WTRESETSTREAM and WTSTOPSENDING).
Fixed by
Thanks for writing this up Alan. This works. Though I'm not sure about the STOPSENDING analogue; QUIC permits the sender to choose the ultimate code for RESETSTREAM, even if it is generally copied from STOPSENDING. I know that we mostly don't need to include RESETSTREAM here as the stream size accounting isn't as critical, so maybe perfect fidelity isn't needed.Thanks NAME

4.2. <ins> The RST_STREAM frame defined in HTTP/2 moves a stream to the "closed" state, but WebTransport streams can be reset unidirectionally, as in QUIC and HTTP/3.  A new HTTP/2 frame called WT_RST_STREAM is introduced for an endpoint to unidirectionally reset a stream for writing.  WT_RST_STREAM frames can be sent on a stream in the "open", or "half-closed (remote)" state. The WT_RST_STREAM frame contains a single unsigned, 32-bit integer identifying the error code.  The error code indicates why the stream is being abruptly terminated for writing. The WT_RST_STREAM frame does not define any flags. The WT_RST_STREAM frame half-closes the referenced stream and effects the same state machine transitions as sending or receiving the END_STREAM flag.  If the sender is in the "open" state, it transitions to "half-closed (local)".  If the sender is in the "half- closed (remote)" state, it transitions to "closed".  If the receiver is in the "open" state, it transitions to "half-closed (remote)".  If the receiver is in the "half-closed (local)" state, it transitions to "closed". After sending a WT_RST_STREAM on a stream, the sender MUST NOT send additional DATA frames for that stream.  If another frame is received on a stream after receiving a WT_RST_STREAM, the recipient MUST treat this as a connection error of type PROTOCOL_ERROR. WT_RST_STREAM frames MUST be associated with a WebTransport stream. If a WT_RST_STREAM frame is received with a stream identifier of 0x0, or a request or push stream, the recipient MUST treat this as a connection error of type PROTOCOL_ERROR. WT_RST_STREAM frames MUST NOT be sent for a stream in any state other than "open" or "half-closed (remote)".  If a WT_RST_STREAM frame identifying a stream in the "idle", "reserved (local)", "reserved (remote)" state is received, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.  Because of race conditions with WT_STOP_SENDING, it is possible to receive a WT_RST_STREAM in the "half-closed (remote)" or "closed" state.  The recipient should ignore the frame in this case. A WT_RST_STREAM frame with a length other than 4 octets MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR. 4.3. The RST_STREAM frame defined in HTTP/2 moves a stream to the "closed" state, but WebTransport streams can be reset unidirectionally, as in QUIC and HTTP/3.  A new HTTP/2 frame called WT_STOP_SENDING is introduced for an endpoint to unidirectionally reset a stream for reading.  WT_STOP_SENDING frames can be sent on a stream in the "open", or "half-closed (local)" state. The WT_STOP_SENDING frame contains a single unsigned, 32-bit integer identifying the error code.  The error code indicates why the reading the stream is being abandoned. The WT_STOP_SENDING frame does not define any flags. The WT_STOP_SENDING frame half-closes the referenced stream and effects the same state machine transitions as sending or receiving the END_STREAM flag.  If the sender is in the open state, it transitions to "half-closed (remote)".  If the sender is in the "half-closed (local)" state, it transitions to "closed".  If the receiver is in the "open" state, it transitions to "half-closed (local)".  If the receiver is in the "half-closed (remote)" state, it transitions to "closed". After receiving a WT_STOP_SENDING on a stream, the sender MUST NOT send additional frames for that stream.  After sending the WT_STOP_SENDING, the sending endpoint MUST be prepared to receive and handle additional frames sent on the stream that might have been sent by the peer prior to the arrival of the WT_STOP_SENDING. WT_STOP_SENDING frames MUST be associated with a WebTransport stream. If a WT_STOP_SENDING frame is received with a stream identifier of 0x0, or a request or push stream, the recipient MUST treat this as a connection error of type PROTOCOL_ERROR. WT_STOP_SENDING frames MUST NOT be sent for a stream in any state other than "open" or "half-closed (local)".  It is possible to receive a WT_STOP_SENDING in another state however, because the sender might have closed or reset the stream while the WT_STOP_SENDING was in flight.  If a WT_STOP_SENDING frame identifying a stream that is already "closed" or "half-closed (local)", the recipient SHOULD ignore the frame. It is also possible to receive DATA frames on a WebTransport stream in the "half-closed (remote)" or "closed" states if the stream transitioned there via WT_STOP_SENDING.  If a DATA frame is received on a WebTransport stream in one of these states, the recipient MUST account for its contribution against the connection flow-control window and MUST NOT treat it as an error. A WT_STOP_SENDING frame with a length other than 4 octets MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR. 4.4. </ins> A new HTTP/2 frame called WT_DATAGRAM is introduced for either endpoint to transmit a datagram.  WT_DATAGRAM frames are sent with Stream Identifier 0. This document <ins> The "WT_RST_STREAM" frame allows HTTP/2 WebTransport streams to be unidirectionally reset for writing: 0xTBD WEBTRANSPORT_RST_STREAM This document The "WT_STOP_SENDING" frame allows HTTP/2 WebTransport streams to be unidirectionally reset for reading: 0xTBD WEBTRANSPORT_STOP_SENDING This document </ins> The "WT_DATAGRAM" frame allows HTTP/2 client and server to exchange datagrams used by WebTransport:


2. <del> WebTransport servers are identified by a pair of authority value and path value (defined in RFC3986 Sections 3.2 and 3.3 correspondingly). </del>  When an HTTP/2 connection is established, both the client and server have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to

This might seem unfortunate, but it's how the protocol works. Update the link to point to HTTP spec instead.

2.  <ins> WebTransport servers are identified by an HTTPS URI as defined in Section 4.2.2 of HTTP. </ins> When an HTTP/2 connection is established, both the client and server have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to


3.2. <del> RFC8441 defines an extended CONNECT method in Section 4, enabled by </del>  the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint does not need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT In order to create a new WebTransport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) <del> MUST be set to "webtransport" (Section 7.1 WEBTRANSPORT-H3).  The </del>  ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided

There was a local reference that was just typed out. The references to other documents cargo-culted from QUIC, but that only works if the documents are in the same repo. You have to pull references from the datatracker. Use the nice reference format in a few places.

3.2.  <ins> RFC8441 defines an extended CONNECT method in features, enabled by </ins> the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint does not need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT In order to create a new WebTransport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441)  <ins> MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The </ins> ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided


Abstract <del> WebTransport OVERVIEW is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport.  This document describes a WebTransport protocol that uses HTTP semantics to provide support for unidirectional streams, bidirectional streams, and datagrams. This protocol can be used with any HTTP version, however this document focuses on TCP-based HTTP versions, specifically providing examples of these capabilities when multiplexed within the same HTTP/2 RFC7540 connection. </del>  Note to Readers 1. <del> This protocol satisfies the WebTransport protocol framework's requirements using HTTP semantics to provide support for </del>  unidirectional streams, bidirectional streams, and datagrams. <del> By using HTTP semantics, this protocol allows deployment using any HTTP version, although this document in particular focuses on HTTP/2 as the current most common TCP-based fallback to HTTP/3 running over QUIC RFC9000. Currently, the only mechanism in HTTP/2 for server to client communication is server push.  That is, servers can initiate unidirectional push promised streams to clients, but clients cannot respond to them; they can only accept them or discard them. Additionally, intermediaries along the path may have different server push policies and may not forward push promised streams to the downstream client.  This best effort mechanism is not sufficient to reliably deliver messages from servers to clients, limiting server to client use-cases such as chat messages or notifications. Several techniques have been developed to workaround these limitations: long polling RFC6202, WebSocket RFC8441, and tunneling using the CONNECT method.  All of these approaches have limitations. This document defines a mechanism for establishing bidirectional communication using HTTP semantics in a manner that conforms with the WebTransport protocol requirements and semantics OVERVIEW.  When running with HTTP/2, multiple WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/2 connection. It is important to note that, while it is possible to have the WebTransport session remain entirely "self contained" within a given HTTP flow, certain HTTP versions may provide native features, such as datagram support, which can allow for a better performing implementation of the WebTransport client's requirements. </del>  1.1. Note that this document distinguishes between a WebTransport server and an HTTP/2 server.  An HTTP/2 server is the server that terminates HTTP/2 connections; a WebTransport server is an application that <del> accepts WebTransport sessions, which can be accessed via an HTTP/2 server. </del>  2.

There is a long and proud legacy of drafts that carry introductions concentrating on the motivations for the last design change rather than the true reasons for the protocol. This is my attempt to bring things back on the level. I didn't stop there though. I think that we should make this about HTTP/2 because we don't currently have an extended CONNECT defined for HTTP/1.1. This walks back some of the "generic HTTP" language. More changes might be needed later in the document for that to be complete, but I wanted to keep this fix localized. I did cut stuff that I think the document should still contain. I just don't think that these need to be in the introduction. That is: you can multiplex multiple sessions other protocols might take stuff from this session and transmit them in different, better ways

Abstract  <ins> WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients.  This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2.  This protocol enables the use of WebTransport when a UDP-based protocol is not available. </ins> Note to Readers 1.  <ins> WebTransport OVERVIEW is designed to provide generic communication capabilities to Web clients that use HTTP/3 HTTP3.  The HTTP/3 WebTransport protocol WEBTRANSPORT-H3 allows Web clients to use QUIC QUIC features such as streams or datagrams DATAGRAM.  However, there are some environments where QUIC cannot be deployed. This document defines a protocol that provides all of the core functions of WebTransport using HTTP semantics.  This includes </ins> unidirectional streams, bidirectional streams, and datagrams.  <ins> By relying only on generic HTTP semantics, this protocol might allow deployment using any HTTP version.  However, this document only defines negotiation for HTTP/2 H2 as the current most common TCP- based fallback to HTTP/3. </ins> 1.1. Note that this document distinguishes between a WebTransport server and an HTTP/2 server.  An HTTP/2 server is the server that terminates HTTP/2 connections; a WebTransport server is an application that  <ins> accepts WebTransport sessions, which can be accessed using HTTP/2 and this protocol. </ins> 2.


MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired <del> WebTransport server.  An "Origin" header { {!RFC6454}} MUST be provided within the request. </del>  Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server can check if it has a

Two things: Say what the header contains Limit it to the Web And fix the xref formatting.

MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired  <ins> WebTransport server.  In a Web context, the request MUST include an "Origin" header field ORIGIN that includes the origin of the site that requested the creation of the session. </ins> Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server can check if it has a


that requested the creation of the session. Upon receiving an extended CONNECT request with a ":protocol" field <del> set to "webtransport", the HTTP server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4,RFC7231).  If it does, it MAY accept the session by replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del>  From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's

The resource does. It's a fine distinction, but an important one.
An excellent distinction, thank you :)

that requested the creation of the session. Upon receiving an extended CONNECT request with a ":protocol" field  <ins> set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not, the server SHOULD reply with status code 404 (Section 6.5.4 of RFC7231).  To accept a WebTransport session the server replies with 2xx status code.  Before accepting a session, a server MUST ensure that it authorizes use of the session by the site identified in the "Origin" header. </ins> From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's


frames and can also be used to provide protection against traffic analysis or for other reasons. <del> The padding extends to the end of the WT_PADDING frame and that many bytes can be discarded by the recipient. </del>  5.2.

The frame format depends on having a definition. I've also made a requirement for this to be zero values. Do we need to say that recipients MUST NOT validate this or that they MAY opt to avoid validation.

frames and can also be used to provide protection against traffic analysis or for other reasons.  <ins> The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field. </ins> 5.2.


A variable-length integer containing the application protocol error code that indicates why the stream is being closed. <del> Final Size: A variable-length integer indicating the final size of the stream by the WT_RESET_STREAM sender, in units of bytes.  This is the amount of flow control credit that is consumed by a stream, see Section 4.5 of RFC9000. </del>  5.3.

And explain the difference.
Updated for merge conflicts, merging this now since whatever the capsule discussion outcome, we know we're going to remove final size
This field isn't necessary because of the in-order, reliable delivery of the underlying transport. That said, I'm not opposed to leaving it here for symmetry with QUIC. We could also say - it's unused, or what to do if this value is different from the value computed as the size of sent data on this stream? Originally posted by NAME in URL
I think that we should remove it. The frame format is not identical to QUIC as you have added lengths to all of the frames. This is a good choice, I think, but it means that you don't have an identical parser. As we have QUIC rules for RESET_STREAM and we have in-order delivery, we can guarantee that there is no ambiguity about how much data was consumed from the "session" flow control limit, so the added field is just another thing to check.
Should we make the length be first in every frame so we can strip it and use the same parser?
That is an interesting suggestion. It is even ... Sort of ... Consistent with HTTP/2.
I guess WebTransport frames are explicitly not capsules, but they are the same as capsules, I think? Capsules are explicitly "TLV".
Yeah, I'm expecting we'll have a slide at 112 about the lengths. QUIC has them for the frames where you have something that varies in length, and I put it in every frame here. Seems like the best choices are either (a) decide that was unnecessary and take them out or (b) move them to the front to make it easier. We also need to see if it would be a capsule or not. Seems like for this issue, we need to decide whether or not we're okay keeping "useless" fields solely for the sake of looking like QUIC. If so, moving length to the front and then keeping the rest of the frame identical seems great. If not, then out with the extra and the position of length doesn't matter nearly as much. Will raise at 112 so we can settle on "useless" fields.
Do we think that WT over H2 should be using Capsules? In particular it might seem silly to have two different ways to send a DATAGRAM. If we think that all WT Frames should be capsules, and we want length up front, we need to take that up in MASQUE. Besides Final Offset, are there any other "useless" fields?
Chair notes from IETF 112 meeting: this is on hold pending which is itself on hold pending output of MASQUE HTTP Datagrams design team
Also from 112: No strong desire to keep things exactly aligned with QUIC frames, so fine to have length in any position and to remove final length.
Text is great, just holding while we decide .Of course it's not needed in this context, but the 1:1 mapping is a nice feature because it promotes code re-use with a QUIC parser. Doesn't seem like it's that sharp an edge if we remove it, but I reserve the right to grumble when I implement it.

A variable-length integer containing the application protocol error code that indicates why the stream is being closed.  <ins> Unlike the equivalent QUIC frame, this frame does not include a Final Size field.  In-order delivery of WT_STREAM frames ensures that the amount of session-level flow control consumed by a stream is always known by both endpoints. </ins> 5.3.


The WT_RESET_STREAM frame defines the following fields: <del> Stream ID: A variable-length integer encoding of the WebTransport stream ID of the stream being terminated. </del>  <del> Application Protocol Error Code: A variable-length integer containing the application protocol error code that indicates why the stream is being closed. </del>  Final Size: A variable-length integer indicating the final size of the stream by the WT_RESET_STREAM sender, in units of bytes.  This is The WT_STOP_SENDING frame defines the following fields: <del> Stream ID: A variable-length integer carrying the WebTransport stream ID of the stream being ignored. </del>  <del> Application Protocol Error Code: A variable-length integer containing the application-specified reason the sender is ignoring the stream. </del>  5.4. WT_MAX_DATA frames contain the following field: <del> Maximum Data: A variable-length integer indicating the maximum amount of data that can be sent on the entire connection, in units of bytes. </del>  All data sent in WT_STREAM frames counts toward this limit.  The sum of the lengths of Stream Data fields in WT_STREAM frames MUST NOT WT_MAX_STREAM_DATA frames contain the following fields: <del> Stream ID: The stream ID of the affected WebTransport stream, encoded as a variable-length integer. </del>  <del> Maximum Stream Data: A variable-length integer indicating the maximum amount of data that can be sent on the identified stream, in units of bytes. </del>  All data sent in WT_STREAM frames for the identified stream counts toward this limit.  The sum of the lengths of Stream Data fields in WT_MAX_STREAMS frames contain the following field: <del> Maximum Streams: A count of the cumulative number of streams of the corresponding type that can be opened over the lifetime of the connection.  This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^(62-1). </del>  An endpoint MUST NOT open more streams than permitted by the current stream limit set by its peer.  For instance, a server that receives a WT_DATA_BLOCKED frames contain the following field: <del> Maximum Data: A variable-length integer indicating the session-level limit at which blocking occurred. </del>  5.9. WT_STREAM_DATA_BLOCKED frames contain the following fields: <del> Stream ID: A variable-length integer indicating the WebTransport stream that is blocked due to flow control. </del>  <del> Maximum Stream Data: A variable-length integer indicating the offset of the stream at which the blocking occurred. </del>  5.10. WT_STREAMS_BLOCKED frames contain the following field: <del> Maximum Streams: A variable-length integer indicating the maximum number of streams allowed at the time the frame was sent.  This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^(62-1). </del>  5.11. WT_DATAGRAM frames contain the following fields: <del> Length: A variable-length integer specifying the length of the Datagram Data in bytes.  Note that empty (i.e., zero-length) datagrams are allowed. Datagram Data: The content of the datagram to be delivered. </del>  The data in WT_DATAGRAM frames is not subject to flow control.  The receiver MAY discard this data if it does not have sufficient space

Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).

The WT_RESET_STREAM frame defines the following fields:  <ins> A variable-length integer encoding of the WebTransport stream ID of the stream being terminated. </ins>  <ins> A variable-length integer containing the application protocol error code that indicates why the stream is being closed. </ins> Final Size: A variable-length integer indicating the final size of the stream by the WT_RESET_STREAM sender, in units of bytes.  This is The WT_STOP_SENDING frame defines the following fields:  <ins> A variable-length integer carrying the WebTransport stream ID of the stream being ignored. </ins>  <ins> A variable-length integer containing the application-specified reason the sender is ignoring the stream. </ins> 5.4. WT_MAX_DATA frames contain the following field:  <ins> A variable-length integer indicating the maximum amount of data that can be sent on the entire connection, in units of bytes. </ins> All data sent in WT_STREAM frames counts toward this limit.  The sum of the lengths of Stream Data fields in WT_STREAM frames MUST NOT WT_MAX_STREAM_DATA frames contain the following fields:  <ins> The stream ID of the affected WebTransport stream, encoded as a variable-length integer. </ins>  <ins> A variable-length integer indicating the maximum amount of data that can be sent on the identified stream, in units of bytes. </ins> All data sent in WT_STREAM frames for the identified stream counts toward this limit.  The sum of the lengths of Stream Data fields in WT_MAX_STREAMS frames contain the following field:  <ins> A count of the cumulative number of streams of the corresponding type that can be opened over the lifetime of the connection.  This value cannot exceed 2 , as it is not possible to encode stream IDs larger than 2 -1. </ins> An endpoint MUST NOT open more streams than permitted by the current stream limit set by its peer.  For instance, a server that receives a WT_DATA_BLOCKED frames contain the following field:  <ins> A variable-length integer indicating the session-level limit at which blocking occurred. </ins> 5.9. WT_STREAM_DATA_BLOCKED frames contain the following fields:  <ins> A variable-length integer indicating the WebTransport stream that is blocked due to flow control. </ins>  <ins> A variable-length integer indicating the offset of the stream at which the blocking occurred. </ins> 5.10. WT_STREAMS_BLOCKED frames contain the following field:  <ins> A variable-length integer indicating the maximum number of streams allowed at the time the frame was sent.  This value cannot exceed 2 , as it is not possible to encode stream IDs larger than 2 -1. </ins> 5.11. WT_DATAGRAM frames contain the following fields:  <ins> The content of the datagram to be delivered. </ins> The data in WT_DATAGRAM frames is not subject to flow control.  The receiver MAY discard this data if it does not have sufficient space


6.  An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 7. </del>  The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence TLS.  Without such support, Http2Transport connections cannot survive network transitions. <del> 8. </del>  WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 9. </del>  <del> 9.1. </del>  The following entry is added to the "HTTP/2 Settings" registry established by RFC7540: This document <del> 9.2. An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the example in Section 5.1 of RFC8441 to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame. 10.  References </del>  <del> 10.1.  URIs </del>  [1] mailto:webtransport@ietf.org

There is not "right" place to put these, but as they are fairly large (and not that useful, frankly), I am going to suggest that they go after the frame definitions.
Yeah, these used to describe how you'd handle a bunch of new concepts, this is now pretty basic and not particularly enlightening. Mayyyybe useful for the establishment, if you've never seen Extended CONNECT, but... yeah. Seems good to move around now and we can cut it later if we don't end up adding anything useful to them. (I also updated with the section reference change from the other PRs to fix up conflicts, since this moved one of those)
I think these have evolved through various versions of the drafts. When the original draft was presented, things like a "CONNECT stream" and how other streams relate to it were not common knowledge, so the examples were maybe more useful. If everyone has got the idea, we can drop it.

6. <ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the example in Section 5.1 of RFC8441 to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame. 7. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session.  <ins> 8. </ins> The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence TLS.  Without such support, Http2Transport connections cannot survive network transitions.  <ins> 9. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  <ins> 10. </ins>  <ins> 10.1. </ins> The following entry is added to the "HTTP/2 Settings" registry established by RFC7540: This document  <ins> 11.  References </ins>  <ins> 11.1.  URIs </ins> [1] mailto:webtransport@ietf.org


4.2. <del> WebTransport streams have states that mirror the states of QUIC streams (Section 3 of RFC9000) as closely as possible to aid in ease of implementation. </del>  Because WebTransport does not provide an acknowledgement mechanism for WebTransport frames, it relies on the underlying transport's in

Attempting to be minimal and just point at RFC9000.
Do we talk about the stream ID numbering space here? It could be completely scoped to the WebTransport session, which is different than H3. Originally posted by NAME in URL
Thanks for doing that.

4.2.  <ins> WebTransport streams have identifiers and states that mirror the identifiers ((Section 2.1 of RFC9000)) and states (Section 3 of RFC9000) of QUIC streams as closely as possible to aid in ease of implementation. WebTransport streams are identified by a numeric value, or stream ID. Stream IDs are only meaningful within the WebTransport session in which they were created.  They share the same semantics as QUIC stream IDs, with client initiated streams having even-numbered stream IDs and server-initiated streams having odd-numbered stream IDs. Similarly, they can be bidirectional or unidirectional, indicated by the second least significant bit of the stream ID. </ins> Because WebTransport does not provide an acknowledgement mechanism for WebTransport frames, it relies on the underlying transport's in


<del> WebTransport using HTTP/2 </del>  draft-ietf-webtrans-http2-latest Abstract

woohoo, making real progress!
The HTTP/2 draft uses "using". This one uses "over". This looks bad in my (sidebar) browser tabs.
HTTP/3 draft describes itself as "a mapping of HTTP semantics over QUIC", so I moderately prefer "over" based on that precedent (and well, the fact that all drafts that I wrote use "over").

<ins> WebTransport over HTTP/2 </ins> draft-ietf-webtrans-http2-latest Abstract


WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. <del> From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. Both endpoints MUST NOT send any WebTransport capsules on a given session before that session is established. </del>  3.4.

I don’t agree with this. A client can send a request body without awaiting a response. Always. Originally posted by NAME in URL
Are those concerns orthogonal? I don't believe there is anything in the text that says you cannot send data before the session is established.
I don't think that this is necessary, or helpful. And I don't think that you can police it either. It is true that a client cannot initiate any streams before the session is created (because the stream limits start at zero), but I see no reason not to pipeline WTDATAGRAM or MAX frames if the h2-level flow control permits it. The MAX_ frames are particularly useful in that they allow the server to send real data immediately, cutting a round trip off.
Given that the limits start at zero (do we state that explicitly anywhere?), and we're not including any sort of SETTINGS/default settings, it definitely seems like we ought to be able to just start spewing frames into the CONNECT stream, which are discarded if the CONNECT request is rejected.
Chair: discussed at 113, consensus in room to allow sending any frames allowed by flow control
Text in H3 here: URL, can probably make it look similar for H2.

WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.  <ins> A WebTransport session is established when the server sends a 200 response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a server, a server MUST NOT process any capsules on the request stream unless it accepts the WebTransport session. A client MAY optimistically send any WebTransport capsules associated with a CONNECT request, without waiting for a response, to the extent allowed by flow control.  This can reduce latency for data sent by a client at the start of a WebTransport session.  For example, a client might choose to send datagrams or flow control updates before receiving any response from the server. </ins> 3.4.


Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not, <del> the server SHOULD reply with status code 404 (Section 6.5.4 of RFC7231).  If it does, it MAY accept the session by replying with a </del>  2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.

Change 404 to 406 Not Acceptable
Current text: >Upon receiving an extended CONNECT request with a field set to , the HTTP server checks if the identified resource supports WebTransport sessions. If the resource does not, the server SHOULD reply with status code 404 ({{Section 6.5.4 of !RFC7231}}). If it does, it MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of {{!SEMANTICS=I-D.ietf-httpbis-semantics}}. The WebTransport server MUST verify the header to ensure that the specified origin is allowed to access the server in question. Originally posted by NAME in URL
The corresponding text in HTTP/3 appears to be: This is correct, though I am not sure how necessary it is.
Discussed in editor's call: 406 sounds good

Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not,  <ins> the server SHOULD reply with status code 406 (Section 15.5.7 of RFC9110).  If it does, it MAY accept the session by replying with a </ins> 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.


7.  An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 8. </del>  WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 9. </del>  <del> 9.1. </del>  The following entries are added to the "HTTP/2 Settings" registry established by RFC7540: This document <del> 9.2. </del>  The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: None <del> 10.  References </del>  <del> 10.1.  URIs </del>  [1] mailto:webtransport@ietf.org [11] mailto:webtransport@ietf.org  Index P

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 can'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 URL
Any reason why you did not do a single header field, like: Then at least the common repetitive stuff isn't repeated.

7. <ins> WebTransport over HTTP/2 uses the "WebTransport-Init" HTTP header field to communicate the initial values of the flow control windows, similar to how QUIC uses transport parameters.  The "WebTransport- Init" is a Dictionary Structured Field (Section 3.2 of RFC8941).  If any of the fields cannot be parsed correctly or do not have the correct type, the peer MUST reset the CONNECT stream.  The following keys are defined for the "WebTransport-Init" header field: 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. 8. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session.  <ins> 9. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  <ins> 10. </ins>  <ins> 10.1. </ins> The following entries are added to the "HTTP/2 Settings" registry established by RFC7540: This document  <ins> 10.2. </ins> The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: None  <ins> 10.3. </ins>  <ins> IANA will register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at https://www.iana.org/assignments/http-fields [12]: WebTransport-Init None permanent This document None 11.  References 11.1.  URIs </ins> [1] mailto:webtransport@ietf.org [11] mailto:webtransport@ietf.org <ins> [12] https://www.iana.org/assignments/http-fields </ins> Index P


between other HTTP datagrams and can also be used to provide protection against traffic analysis or for other reasons.  The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field.

This is not a bad thing. In fact it's a deliberate choice. It might be worth noting the redundancy so people don't think we're a bit dim. We might also add that this padding is less tunable than h2 padding.
Do we actually need WT_PADDING, and if so, does it need to be in this document?
NAME do you remember why we deliberately chose to have this separate padding instead of just relying on the h2 padding?
I don't recall the specifics 18 months on. However, the basic problems are invariant. The different padding schemes offer different capabilities due to a bunch of different design trade-offs and inherent properties of each approach. h2 padding only applies to one hop, but WTPADDING would traverse intermediaries (because it is application data as far as they are concerned). Consequently, you might want to use WTPADDING if your goal is to protect against leaks on remote hops. This is because each operates on a different scope. WTPADDING doesn't get to be smaller than the minimum capsule size, but h2 padding can be any size. That means that a padding strategy is potentially more efficient in h2 as you need to include WTPADDING and its overheads. This is because the more padding integration in h2 is more complete, but also more complex. Finally, there are all the usual software engineering constraints. Maybe you have access to padding functions in your WT stack, but not the h2 stack.
Many thanks NAME Added a version of that to the padding section (noting that padding is a generic capsule being defined here, so others can use it even if not over HTTP/2).

between other HTTP datagrams and can also be used to provide protection against traffic analysis or for other reasons. <ins> Note that, when used with WebTransport over HTTP/2, the capsule exists alongside the ability to pad HTTP/2 frames (Section 10.7 of RFC9113).  HTTP/2 padding is hop-by-hop and can be modified by intermediaries, while the capsule traverses intermedaries.  The capsule is also constrained to be no smaller than the capsule overhead itself. </ins> The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field.


4.1.  Because WebTransport over TCP-based HTTP semantics relies on the underlying protocols to provide in order and reliable delivery, there are some notable differences from the way in which QUIC handles <del> application data. Endpoints MUST send stream data in order.  As there is no ordering mechanism available for the receiver to reassemble incoming data, receivers assume that all data arriving in capsules is contiguous and in order. DATAGRAM capsules are delivered to the remote WebTransport endpoint reliably, however this does not require that the receiving implementation deliver that data to the application in a reliable manner. </del>  4.2. for flow control purposes and MUST generate and send appropriate flow control signals for their limits. <del> 6. </del>  WebTransport over HTTP/2 uses the DATAGRAM capsule defined in Section 3.5 of HTTP-DATAGRAM to carry datagram traffic. intermediaries follow the requirements in WEBTRANSPORT-H3 to use native QUIC datagrams. <del> 7. </del>  An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the The only difference here is the endpoint that sends the first capsule. <del> 8. </del>  An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 9. The WebTransport capsulework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols. Below are details about support in Http2Transport for those properties. Http2Transport does not support stream independence, as HTTP/2 inherently has head of line blocking. Http2Transport does not support partial reliability, as HTTP/2 retransmits any lost data.  This means that any datagrams sent via Http2Transport will be retransmitted regardless of the preference of the application.  The receiver is permitted to drop them, however, if it is unable to buffer them. Http2Transport supports pooling, as multiple transports using Http2Transport may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context. Http2Transport does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP MPTCP, is used underneath HTTP/2 and TLS. Without such support, Http2Transport connections cannot survive network transitions. 10. </del>  WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 11. </del>  <del> 11.1. </del>  The following entries are added to the "HTTP/2 Settings" registry established by RFC7540: This document <del> 11.2. </del>  The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: None <del> 12.  References </del>  <del> 12.1.  URIs </del>  [1] mailto:webtransport@ietf.org

Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.

4.1. <ins> The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols. </ins> Because WebTransport over TCP-based HTTP semantics relies on the underlying protocols to provide in order and reliable delivery, there are some notable differences from the way in which QUIC handles  <ins> application data.  For example, endpoints send stream data in order. As there is no ordering mechanism available for the receiver to reassemble incoming data, receivers assume that all data arriving in capsules is contiguous and in order. Below are details about support in WebTransport over HTTP/2 for the properties defined by the WebTransport framework. WebTransport over HTTP/2 does not support stream independence, as HTTP/2 inherently has head-of-line blocking. WebTransport over HTTP/2 does not support partial reliability, as HTTP/2 retransmits any lost data.  This means that any datagrams sent via WebTransport over HTTP/2 will be retransmitted regardless of the preference of the application.  The receiver is permitted to drop them, however, if it is unable to buffer them. WebTransport over HTTP/2 supports pooling, as multiple transports using WebTransport over HTTP/2 may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context.  Note that WebTransport streams over HTTP/2 are contained within a single HTTP/2 stream and do not compete with other pooled WebTransport sessions for per-stream resources. WebTransport over HTTP/2 does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP MPTCP, is used underneath HTTP/2 and TLS. Without such support, WebTransport over HTTP/2 connections cannot survive network transitions. </ins> 4.2. for flow control purposes and MUST generate and send appropriate flow control signals for their limits.  <ins> 5.11. </ins> WebTransport over HTTP/2 uses the DATAGRAM capsule defined in Section 3.5 of HTTP-DATAGRAM to carry datagram traffic. intermediaries follow the requirements in WEBTRANSPORT-H3 to use native QUIC datagrams.  <ins> 6. </ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the The only difference here is the endpoint that sends the first capsule.  <ins> 7. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session.  <ins> 8. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  <ins> 9. </ins>  <ins> 9.1. </ins> The following entries are added to the "HTTP/2 Settings" registry established by RFC7540: This document  <ins> 9.2. </ins> The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: None  <ins> 10.  References </ins>  <ins> 10.1.  URIs </ins> [1] mailto:webtransport@ietf.org


WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. <del> A WebTransport session is established when the server sends a 200 </del>  response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a

The document currently mentions HTTP status code 200 explicitly, instead of following the usual convention of saying "any 2xx" status code. We already made this change in WebTransport over HTTP/3, we should do the same in this doc.
Ack, we're a bit mixed in the HTTP/2 document right now, will update so we're consistent everywhere.

WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.  <ins> A WebTransport session is established when the server sends a 2xx </ins> response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a


HTTP/2 stream flow control, which limits the data on a single HTTP/2 stream.  For a WebTransport session, this includes all <del> capsules, including those that are exempt from session-level flow control. </del>  WebTransport session-level flow control, which limits the total amount of stream data that can be sent or received on streams <del> within the WebTransport session. </del>  WebTransport stream flow control, which limits data on individual streams within a session. 3.4.2.  WebTransport over HTTP/2 uses several capsules for flow control, and all of these capsules define special intermediary handling as described in Section 3.2 of HTTP-DATAGRAM.  These capsules, referred

Expand description of flow control and add additional notes NAME already wrote up a very nice overview of the layers we have, so added a little bit extra there and filled in the last little bit on limiting streams within a session to round everything out.
Document how MAXDATA interacts with the enclosing HTTP/2 flow control scheme Originally posted by NAME in URL
I tend to think we might want to have a section entirely on flow control since we've now got several layers: HTTP/2 connection level HTTP/2 stream for the CONNECT stream WTMAXDATA for the WT session Noting that this is different than the HTTP/2 layer's CONNECT stream, since we want to be able to indicate the sum of stream data separately from other control frames WTMAXSTREAMDATA for each WT stream And stream-count flow control HTTP/2 stream limits don't really apply once you've got the WT session up WTMAX_STREAMS limits stream counts within a WT session Just indicating the intended usage of each of these knobs would be helpful.
(From : Since QUIC's flow control credits work differently from H2, it may be worth explicitly stating how this works here.)
Chair notes from IETF 112 meeting: no one objected to proposal of resolving this by documenting how flow control works and pitfalls
Why do we need WTMAXDATA in first place? I thought that since we have flow control from the HTTP/2 side, we don't need it.
We want to be able to say "don't send me any more data on this stream" while still allowing control frames on that stream

HTTP/2 stream flow control, which limits the data on a single HTTP/2 stream.  For a WebTransport session, this includes all  <ins> capsules, including those that are exempt from WebTransport session-level flow control. </ins> WebTransport session-level flow control, which limits the total amount of stream data that can be sent or received on streams  <ins> within the WebTransport session.  Note that this does not limit other types of capsules within a WebTransport session, such as control messages or datagrams. </ins> WebTransport stream flow control, which limits data on individual streams within a session. 3.4.2. <ins> This document defines a capsule (WT_MAX_STREAMS) that allows each endpoint to limit the number of streams its peer is permitted to open as part of a WebTransport session.  There is a separate limit for bidirectional streams and for unidirectional streams.  Note that, unlike WebTransport over HTTP/3 WEBTRANSPORT-H3, because the entire WebTransport session is contained within HTTP/2 DATA frames on a single HTTP/2 stream, this limit is the only mechanism for an endpoint to limit the number of WebTransport streams that its peer can open on a session. 3.4.3. </ins> WebTransport over HTTP/2 uses several capsules for flow control, and all of these capsules define special intermediary handling as described in Section 3.2 of HTTP-DATAGRAM.  These capsules, referred