jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-webtrans-http2

Commentary: Expand description of flow control and add additional notes already wrote up a very nice overview of the layers we have , so 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 in 
 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 do n'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 do n't need it . 
 We want to be able to say " do n'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
capsules, including those that are exempt from session-level flow
control.
WebTransport session-level flow control, which limits the total
amount of stream data that can be sent or received on streams
within the WebTransport session.
HTTP/2 stream flow control, which limits the data on a single
HTTP/2 stream.  For a WebTransport session, this includes all
capsules, including those that are exempt from WebTransport
session-level flow control.
WebTransport session-level flow control, which limits the total
amount of stream data that can be sent or received on streams
within the WebTransport session.  Note that this does not limit
other types of capsules within a WebTransport session, such as
control messages or datagrams.
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.
Draft: draft-ietf-webtrans-http2

Commentary: 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 . 
  , we 're a bit mixed in the HTTP/2 document right now , will update so we 're consistent everywhere .
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 WebTransport session is established when the server sends a 2xx
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.
Draft: draft-ietf-webtrans-http2

Commentary: This is not a bad thing . In fact it 's a deliberate choice . It might be worth noting the redundancy so people do n'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 ? 
 do you remember why we deliberately chose to have this separate padding instead of just relying on the h2 padding ? 
 I do n'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 does n'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 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 ) .
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.
Draft: draft-ietf-webtrans-http2

Commentary: 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 in 
 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,
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.  The
WebTransport server MUST verify the "Origin" header to ensure that
the specified origin is allowed to access the server in question.
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,
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
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.
Draft: draft-ietf-webtrans-http2

Commentary: I do n’t agree with this . A client can send a request body without awaiting a response . Always . Originally posted by in 
 Are those concerns orthogonal ? I do n't believe there is anything in the text that says you can not send data before the session is established . 
 I do n't think that this is necessary , or helpful . And I do n't think that you can police it either . It is true that a client can not 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 : , can probably make it look similar for H2 .
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.
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.
Draft: draft-ietf-webtrans-http2

Commentary: Reset stream does n't cease retransmission . 
 retransmission of WTSTREAM frames on the identified stream . A receiver of WTRESET_STREAM can discard any data that it already received on that stream . " This is using TCP and should not talk about ceasing retransmissions . 
 Very good point ! Will clean up
After sending a , an endpoint ceases transmission and retransmission
of frames on the identified stream.  A receiver of can discard any
data that it already received on that stream.
After sending a , an endpoint ceases transmission of frames on the
identified stream.  A receiver of can discard any data that it
already received on that stream.
Draft: draft-ietf-webtrans-http2

Commentary: 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 in 
 Thanks for doing that .
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.
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.
Draft: draft-ietf-webtrans-http2

Commentary: ... Not HTTP/2 This section might go , but this is also harmless .
"HTTP_STREAM_REFUSED" error code defined in RFC7540 indicates to
the receiving HTTP/2 stack that the request was not processed in
any way.
"HTTP_STREAM_REFUSED" error code defined in [RFC7540] indicates to
the receiving HTTP/2 stack that the request was not processed in
any way.
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.
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.
Draft: draft-ietf-webtrans-http2

Commentary: 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 ) .
Stream ID: A variable-length integer encoding of the WebTransport
stream ID of the stream being terminated.
Application Protocol Error Code: A variable-length integer containing
the application protocol error code that indicates why the stream is
being closed.
A variable-length integer encoding of the WebTransport stream ID
of the stream being terminated.
A variable-length integer containing the application protocol
error code that indicates why the stream is being closed.
Stream ID: A variable-length integer carrying the WebTransport stream
ID of the stream being ignored.
Application Protocol Error Code: A variable-length integer containing
the application-specified reason the sender is ignoring the stream.
A variable-length integer carrying the WebTransport stream ID of
the stream being ignored.
A variable-length integer containing the application-specified
reason the sender is ignoring the stream.
Maximum Data: A variable-length integer indicating the maximum amount
of data that can be sent on the entire connection, in units of bytes.
A variable-length integer indicating the maximum amount of data
that can be sent on the entire connection, in units of bytes.
Stream ID: The stream ID of the affected WebTransport stream, encoded
as a variable-length integer.
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.
The stream ID of the affected WebTransport stream, encoded as a
variable-length integer.
A variable-length integer indicating the maximum amount of data
that can be sent on the identified stream, in units of bytes.
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).
Maximum Data: A variable-length integer indicating the session-level
limit at which blocking occurred.
A variable-length integer indicating the session-level limit at
which blocking occurred.
Stream ID: A variable-length integer indicating the WebTransport
stream that is blocked due to flow control.
Maximum Stream Data: A variable-length integer indicating the offset
of the stream at which the blocking occurred.
A variable-length integer indicating the WebTransport stream that
is blocked due to flow control.
A variable-length integer indicating the offset of the stream at
which the blocking occurred.
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).
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.
The content of the datagram to be delivered.
Draft: draft-ietf-webtrans-http2

Commentary: QUIC is complicated , this does n't need to be . 
 Much nicer !
All data sent in WT_STREAM frames counts toward this limit.  The sum
of the final sizes on all streams, including streams in terminal
states, MUST NOT exceed the value advertised by a receiver.
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
exceed the value advertised by a receiver.
When counting data toward this limit, an endpoint accounts for the
largest amount of data that is sent or received on the stream.  The
data sent on a stream MUST NOT exceed the largest maximum stream data
value advertised by the receiver.
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_STREAM frames on the identified stream MUST NOT exceed the value
advertised by a receiver.
Draft: draft-ietf-webtrans-http2

Commentary: The definition was a little loose , so I rewrote it . We only need to use 0x0a and 0x0b , which is lucky and it lets us avoid much of the mess that QUIC has around bits in the type . I 've also definitions for the fields in the frame .
The FIN bit (0x01) indicates that the frame marks the end of the
stream.  The final size of the stream is the sum of the length, in
bytes, of all data previously sent on this stream and the length of
this frame without the length of the Stream ID.
frames implicitly create a stream and carry stream data.
The Type field in the frame is either 0x0a or 0x0b.  This uses the
same frame types as a QUIC STREAM frame with the OFF bit clear and
the LEN bit set.  The FIN bit (0x01) in the frame type indicates that
the frame marks the end of the stream in one direction.  Stream data
consists of any number of 0x0a frames followed by a terminal 0x0b
frame.
The stream ID for the stream.
Zero or more bytes of data for the stream.  Empty frames MUST NOT
be used unless they open or close a stream; an endpoint MAY treat
an empty frame that neither starts nor ends a stream as a session
error.
Draft: draft-ietf-webtrans-http2

Commentary: 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 .
The padding extends to the end of the WT_PADDING frame and that many
bytes can be discarded by the recipient.
The Padding field MUST be set to an all-zero sequence of bytes of any
length as specified by the Length field.
Draft: draft-ietf-webtrans-http2

Commentary: The resource does . It 's a fine distinction , but an important one . 
 An excellent distinction , thank you :)
Upon receiving an extended CONNECT request with a ":protocol" field
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.
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,
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.
Draft: draft-ietf-webtrans-http2

Commentary: Two things : what the header contains it to the Web And fix the xref formatting .
In order to create a new WebTransport session, a client can send an
HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441)
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
WebTransport server.  An "Origin" header { {!RFC6454}} MUST be
provided within the request.
In order to create a new WebTransport session, a client can send an
HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441)
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
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.
Draft: draft-ietf-webtrans-http2

Commentary: Ah , bad wrapping , thank you !
The repository tracking the issues for this draft can be found at[]
(https://github.com/ietf-wg-webtrans/draft-webtransport-http2).  The
web API draft corresponding to this document can be found at[]
(https://w3c.github.io/webtransport/).
The repository tracking the issues for this draft can be found at
<https://github.com/ietf-wg-webtrans/draft-webtransport-http2>.  The
web API draft corresponding to this document can be found at
<https://w3c.github.io/webtransport/>.
Draft: draft-ietf-webtrans-http2

Commentary: 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 .
RFC8441 defines an extended CONNECT method in Section 4, enabled by
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
setting implies that an endpoint supports extended CONNECT.
RFC8441 defines an extended CONNECT method in features, enabled by
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
setting implies that an endpoint supports extended CONNECT.
In order to create a new WebTransport session, a client can send an
HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441)
MUST be set to "webtransport" (Section 7.1 WEBTRANSPORT-H3).  The
":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
within the request.
In order to create a new WebTransport session, a client can send an
HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441)
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
WebTransport server.  An "Origin" header RFC6454 MUST be provided
within the request.
Draft: draft-ietf-webtrans-http2

Commentary: This might seem unfortunate , but it 's how the protocol works . Update the link to point to HTTP spec instead .
WebTransport servers are identified by a pair of authority value and
path value (defined in RFC3986 Sections 3.2 and 3.3 correspondingly).
WebTransport servers are identified by an HTTPS URI as defined in
Section 4.2.2 of HTTP.
Draft: draft-ietf-webtrans-http2

Commentary: Add links to the links . Remove , which was n't being used .
Discussion of this draft takes place on the WebTransport mailing list
(webtransport@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=webtransport>.
Discussion of this draft takes place on the WebTransport mailing list
(webtransport@ietf.org [1]), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=webtransport>.