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

Commentary: Fix up references to setting names 
 The draft uses both but I presume they refer to the same thing , so lets pick one . 
 Ah , left over from a previous change , I believe . is the correct form , can update to match . 
 Yep sgtm
In addition to the setting above, the server MUST send a
SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum
number of concurrent sessions it is willing to receive.  The default
value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0",
meaning that the server is not willing to receive any WebTransport
sessions.
In addition to the setting above, the server MUST send a
SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter indicating the maximum
number of concurrent sessions it is willing to receive.  The default
value for the SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter is "0",
meaning that the server is not willing to receive any WebTransport
sessions.
This document defines a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter
that allows the server to limit the maximum number of concurrent
WebTransport sessions on a single HTTP/3 connection.  The client MUST
NOT open more sessions than indicated in the server SETTINGS
parameters.  The server MUST NOT close the connection if the client
opens sessions exceeding this limit, as the client and the server do
not have a consistent view of how many sessions are open due to the
asynchronous nature of the protocol; instead, it MUST reset all of
the CONNECT streams it is not willing to process with the
"HTTP_REQUEST_REJECTED" status defined in HTTP3.
This document defines a SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter
that allows the server to limit the maximum number of concurrent
WebTransport sessions on a single HTTP/3 connection.  The client MUST
NOT open more sessions than indicated in the server SETTINGS
parameters.  The server MUST NOT close the connection if the client
opens sessions exceeding this limit, as the client and the server do
not have a consistent view of how many sessions are open due to the
asynchronous nature of the protocol; instead, it MUST reset all of
the CONNECT streams it is not willing to process with the
"HTTP_REQUEST_REJECTED" status defined in HTTP3.
Draft: draft-ietf-webtrans-http3

Commentary: Noticed we had a few oddly long lines , so I hit the rewrap button . 
 This was Sublime , but many others will attempt to do the same :) 
 What tool do you use that has a rewrap button ?
HTTP/3 HTTP3 is a protocol defined on top of QUIC RFC9000 that can
multiplex HTTP requests over a QUIC connection.  This document
defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a
manner that conforms with the WebTransport protocol requirements and
semantics OVERVIEW.  Using the mechanism described here, multiple
WebTransport instances can be multiplexed simultaneously with regular
HTTP traffic on the same HTTP/3 connection.
HTTP/3 HTTP3 is a protocol defined on top of QUIC RFC9000 that can
multiplex HTTP requests over a QUIC connection.  This document
defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a
manner that conforms with the WebTransport protocol requirements and
semanticsOVERVIEW.  Using the mechanism described here, multiple
WebTransport instances can be multiplexed simultaneously with regular
HTTP traffic on the same HTTP/3 connection.
Draft: draft-ietf-webtrans-http3

Commentary: After sending the CLOSEWEBTRANSPORTSESSION capsule and sending the FIN on the stream , it would make sense to also stop reading on the stream ( by sending a STOP_SENDING ) . Should that be the recommended behavior in the spec ? 
 Chair : discussed at IETF 114 , consensus in the room to allow but not require sending STOP_SENDING 
 The spec currently reads : So it currently recommends setting a timer and then issuing a STOPSENDING . I guess the request here is to send indicate the sender of CLOSEWEBTRANSPORTSESSION may send the  immediately . I 'm going to remove the bit about the timer since it 's not really relevant ? If the closing endpoint wants to wait to see if there 's any other messages in flight on the CONNECT stream that 's fine . The CLOSEWEBTRANSPORTSESSION + FIN + must - respond - with - FIN is an implicit STOP_SENDING . 
 Fix the typo , raise an issue for the other thing .
A CLOSE_WEBTRANSPORT_SESSION capsule MUST be followed by a FIN on the
sender side.  If any additional stream data is received on the
CONNECT stream after CLOSE_WEBTRANSPORT_SESSION, the stream MUST be
reset with code H3_MESSAGE_ERROR.  The recipient MUST close the
stream upon receiving a FIN.  If the sender of
CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some time, it
SHOULD send STOP_SENDING on the CONNECT stream.
An endpoint that sends a CLOSE_WEBTRANSPORT_SESSION capsule MUST
immediately send a FIN.  The endpoint MAY send a STOP_SENDING to
indicate it is no longer reading from the CONNECT stream.  The
recipient MUST close the stream upon receiving a FIN.  If any
additional stream data is received on the CONNECT stream after
receiving a CLOSE_WEBTRANSPORT_SESSION capsule, the stream MUST be
reset with code H3_MESSAGE_ERROR.
Draft: draft-ietf-webtrans-http3

Commentary: In , it was suggested that 403 status code should be used when  verification fails . 
 Thank you for suggestions ! Applied . 
 Thank you for reviews ! If this looks good can someone merge this ? 
 Looking good , thank you ! Added a few suggestions to cause it to generate links to the actual sections referenced , even if it makes it a little more repetitive . Approved modulo one small change
Upon receiving an extended CONNECT request with a ":protocol" field
set to "webtransport", the HTTP/3 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 15.5.4, HTTP).  If it does, it MAY accept the session by
replying with a 2xx series status code, as defined in Section 15.3 of
HTTP.  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/3 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 15.5.5 of HTTP).  When the request contains the "Origin"
header, the WebTransport server MUST verify the "Origin" header to
ensure that the specified origin is allowed to access the server in
question.  If the verification fails, the WebTransport server SHOULD
reply with status code 403 (Section 15.5.4 of HTTP).  If all checks
pass, the WebTransport server MAY accept the session by replying with
a 2xx series status code, as defined in Section 15.3 of HTTP.
Draft: draft-ietf-webtrans-http3

Commentary: This is mostly based on what  currently does in production . 
 Chair : discussed during editor 's meeting , plan is to remove text about 3 PTO and note that delivering other open streams is best - effort . Also add rationale and mention that this aligns with what QUIC does - this message has similar delivery guarantees as the close_connection in QUIC 
 A common use ( at least for non - pooled WebTransport connections ) will be to close the underlying QUIC connection when closing the WebTransport session . This is inherently racy : The sender will send both a CLOSEWEBTRANSPORTSESSION capsule and a QUIC CONNECTIONCLOSE frame ( unless you wait for the peer 's FIN on the request stream , but why would you ? ) . It 's undetermined which one of the two will be received / processed first by the receiver . This is not a problem if the sender uses the same error code and error message for the CONNECTIONCLOSE frame and for the CLOSEWEBTRANSPORTSESSION capsule . Assuming the QUIC stack properly exposes these values on its API , the receiver will be able to learn error code and error message . Should we add that as a recommendation , or even a requirement ? 
 Chair : discussed during editor 's meeting , see
In some scenarios, an endpoint might want to send a
CLOSE_WEBTRANSPORT_SESSION with detailed close information and then
immediately close the underlying QUIC connection.  If the endpoint
were to do both of those simultaneously, the peer could potentially
receive the CONNECTION_CLOSE before receiving the
CLOSE_WEBTRANSPORT_SESSION, thus never receiving the application
error data contained in the latter.  To avoid this, the endpoint
SHOULD wait until all of the data on the CONNECT stream is
acknowledged before sending the CONNECTION_CLOSE; this gives
CLOSE_WEBTRANSPORT_SESSION properties similar to that of the QUIC
CONNECTION_CLOSE mechanism as a best-effort mechanism of delivering
application close metadata.
Draft: draft-ietf-webtrans-http3

Commentary: This is vaguely based on the similar text in the WebSocket RFC . 
 In draft 03 the following requirement is made WebTransport 's closest equivalent in this regard is WebSockets , which does n't mandate the origin header ; see This requirement makes it weird to use for user agents that have no concept of an origin model . So the MUST level seems a bit overzealous . 
 It is not just the user agent . Take for example the proposed use of . That application does not have any concept of " origin " -- indeed , there is no mention of the word " origin " in that draft .
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".  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".  The ":scheme" field MUST be "https".
Both the ":authority" and the ":path" value MUST be set; those fields
indicate the desired WebTransport server.  If the WebTransport
session is coming from a browser client, an "Origin" header RFC6454
MUST be provided within the request; otherwise, the header is
OPTIONAL.
Draft: draft-ietf-webtrans-http3

Commentary: currently states : That is not well - defined : it relies on which only discusses HTTP/2 , and the relevant changes between HTTP/2 and HTTP/3 are subtle . Since we have that is now in the RFC Editor Queue , WebTransport needs to instead refer to that and require servers to send . 
 This sounds like an obvious way forward . That said , I would personally prefer to wait until we make another breaking wire protocol change . 
 Sounds good to me , there 's no rush here - in my personal opinion we just need to get this in before WGLC 
 More generally , it looks like we may want to remove any implied support and just require endpoints to explicitly signal support for each " layer " of capabilities that we 're relying on . 
 Discussed at IETF 115 , consensus in room to require all the relevant settings and transport parameters to be sent individually - for this issue means : require that SETTINGSENABLECONNECT_PROTOCOL be sent
RFC8441 defines an extended CONNECT method in Section 4, enabled by
the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  That parameter is
only defined for HTTP/2.  This document does not create a new multi-
purpose parameter to indicate support for extended CONNECT in HTTP/3;
instead, the SETTINGS_ENABLE_WEBTRANSPORT setting implies that an
endpoint supports extended CONNECT.
RFC8441 defines an extended CONNECT method in Section 4, enabled by
the SETTINGS_ENABLE_CONNECT_PROTOCOL setting.  That setting is
defined for HTTP/3 by RFC9220.  An endpoint supporting WebTransport
over HTTP/3 MUST send both the SETTINGS_ENABLE_WEBTRANSPORT setting
and the SETTINGS_ENABLE_CONNECT_PROTOCOL setting with values set to
"1".
Draft: draft-ietf-webtrans-http3

Commentary: Porting originally posted to W3C WT New connections should be throttled to avoid being a DoS vector . Maybe we will just have some language in the standard to permit and encourage throttling , and leave the details to browsers . 
 Should n't the throttling be performed at the W3C layer ? If throttling happens , should the W3C API let the caller know ? 
 I think this is a back - to - front way of suggesting that WebTransport include something like the guidance in ( which I found , linked from 
 Oh thanks for finding that . I 'm supportive of adding something like that . 
 I 'm actually not sure that the specific requirement in WebSocket spec is useful , compared to just recommending throttling ( or other forms of resource limits ) in general . 
 The WebSocket throttling in RFC6455 requires you to implement it close to the socket layer ( in particular , after DNS lookup ) , which is messy in practice . I think it may be sufficient to leave the details of the throttling to the implementation . If we want to ensure it is interoperable , a per - network - partitiion delay based on the number of pending and recently - failed connections should be sufficient . 
 So given that this is over HTTP/3 , what is the anticipated throttling ? Is it really just trying to tell HTTP clients to not make lots of requests ? Is WebTransport sufficiently more expensive than other types of requests ? I 'm struggling to see language we would include here that is needed over language we have in QUIC or HTTP/3 already 
 Generally a browser will only make one HTTP/3 connection per server , regardless of how many resources the page requests . So servers do n't need to worry about a well - behaved browser initiating large numbers of simultaneous QUIC handshakes . However , when WebTransport connections are not pooled , it is valid to make several at the same time . If there were no restrictions , a badly - behaved web page could request thousands of WebTransport connections simultaneously , DoSing the server . 
 Thanks  . I think phrasing thing as a design deviation from HTTP/3 's recommendation to use one connection is good idea . 
 From what I can read from this discussion , there is n't that much in terms of design here , and this mostly requires writing up that throttling is up to the implementation .
A client could attempt to exhaust resources by opening too many
WebTransport sessions at once.  In cases when the client is
untrusted, the user agent SHOULD limit the number of outgoing
sessions the client can open.
Draft: draft-ietf-webtrans-http3

Commentary: s / an WebTransport / a WebTransport spellings
If at any point a session ID is received that cannot a valid ID for a
client-initiated bidirectional stream, the recepient MUST close the
connection with an H3_ID_ERROR error code.
If at any point a session ID is received that cannot a valid ID for a
client-initiated bidirectional stream, the recipient MUST close the
connection with an H3_ID_ERROR error code.
HTTP/3 does not by itself define any semantics for server-initiated
bidirectional streams.  If WebTransport setting is negotiated by both
endpoints, the syntax of the server-initiated bidirectional streams
SHALL be the same as the syntax of client-initated bidirectional
streams, that is, a sequence of HTTP/3 frames.  The only frame
defined by this document for use within server-initiated
bidirectional streams is WEBTRANSPORT_STREAM.
HTTP/3 does not by itself define any semantics for server-initiated
bidirectional streams.  If WebTransport setting is negotiated by both
endpoints, the syntax of the server-initiated bidirectional streams
SHALL be the same as the syntax of client-initiated bidirectional
streams, that is, a sequence of HTTP/3 frames.  The only frame
defined by this document for use within server-initiated
bidirectional streams is WEBTRANSPORT_STREAM.
A UTF-8 encoded error message string provided by the application
closing the connection.  The message takes up the remainer of the
capsule, and its length MUST NOT exceed 1024 bytes.
A UTF-8 encoded error message string provided by the application
closing the connection.  The message takes up the remainder of the
capsule, and its length MUST NOT exceed 1024 bytes.
Draft: draft-ietf-webtrans-http3

Commentary: If a connection carrying WebTransport sessions receives a GOAWAY , is the sender allowed to continue 1 ) sending datagrams 2 ) creating new WT streams 3 ) receiving new WT streams I assume it 's ok to continue sending data on already open WT streams and the CONNECT stream , but clarification would be good . Also , are the rules any different after sending a GOAWAY ? Can the sender continue doing the above ? 
 I 'll just note that because in H2 WT streams are contained to a single stream , they are implicitly allowed there unless we forbid them . 
 Chair : discussed at IETF 113 , consensus to have GOAWAY not prevent opening new WT streams on existing WT sessions . will write a PR
HTTP/3 defines a graceful shutdown mechanism (Section 5.2 of HTTP3)
that allows a peer to send a GOAWAY frame indicating that it will no
longer accept any new incoming requests or pushes.  This mechanism
applies to the CONNECT requests for new WebTransport sessions.  A
GOAWAY frame does not affect data streams for existing WebTransport
sessions; those can continue to be opened even after the GOAWAY frame
has been sent or received.
Draft: draft-ietf-webtrans-http3

Commentary: This change both describes the existing mechanism ( SETTINGS ) . It also adds a header in the unlikely scenario that we would need to change capsule stream format ( instead of just defining new capsules ) .
WebTransport over HTTP/3 uses two different mechanisms to negotiate
versions for the different parts of the draft.
The hop-by-hop wire format aspects of the protocol are negotiated by
changing the codepoint used for the SETTINGS_ENABLE_WEBTRANSPORT
parameter.  Because of that, any WebTransport endpoint MUST wait for
the peer's SETTINGS frame before sending or processing any
WebTransport traffic.  When multiple versions are supported by both
of the peers, the most recent version supported by both is selected.
The data exchanged over the CONNECT stream is transmitted across
intermediaries, and thus cannot be versioned using a SETTINGS
parameter.  To indicate support for different versions of the
protocol defined in this draft, the clients SHALL send a header for
each version of the draft supported.  The header corresponding to the
version described in this draft is "Sec-Webtransport-Http3-Draft02";
its value SHALL be "1".  The server SHALL reply with a "Sec-
Webtransport-Http3-Draft" header indicating the selected version; its
value SHALL be "draft02" for the version described in this draft.
Draft: draft-ietf-webtrans-http3

Commentary: This PR keeps WebTransport in sync with the latest changes in draft - ietf - masque - h3 - datagram .
A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM.
A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM.
If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC
DATAGRAMs within HTTP/3 MUST be negotiated as described in
HTTP3-DATAGRAM; negotiating WebTransport support without negotiating
HTTP/3 DATAGRAM support SHALL result in a H3_SETTINGS_ERROR error.
The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as
defined in HTTP-DATAGRAM.
Datagrams can be sent using the DATAGRAM frame as defined in QUIC-
DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the
SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow
Identifier is set to the session ID.  In other words, the format of
datagrams SHALL be the session ID, followed by the user-specified
payload (fig-datagram).
Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT
HTTP Datagram Format Type (see value in iana-format-type).  When
using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport
datagram payload is sent unmodified in the "HTTP Datagram Payload"
field of an HTTP Datagram.  When sending a registration capsule using
the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format
Additional Data" field SHALL be empty.
This document.
Draft: draft-ietf-webtrans-http3

Commentary: This makes our behavior consistent with the regular CONNECT method . 
 The spec currently explicitly requires . that any 2xx code should work . Should we change the text accordingly ? 
 I 'd suggest server MUST send 200 and client MUST accept any 2XX . That way future extensions can apply meaning to other 2XX codes . 
 What would happen if we require client to reject 2xx other than 200 ?
Upon receiving an extended CONNECT request with a ":protocol" field
set to "webtransport", the HTTP/3 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.
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.
WebTransport over HTTP/3 does not support 0-RTT.
Upon receiving an extended CONNECT request with a ":protocol" field
set to "webtransport", the HTTP/3 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 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.
From the client's perspective, a WebTransport session is established
when the client receives a 2xx response.  From the server's
perspective, a session is established once it sends a 2xx response.
WebTransport over HTTP/3 does not support 0-RTT.
Draft: draft-ietf-webtrans-http3

Commentary: This requirement has been irrelevant since quicwg / base - drafts
HTTP3 requires client's "initial_max_bidi_streams" transport
parameter to be set to zero.  Existing implementation might enforce
this requirement before negotiating settings; thus, the client MUST
send a non-zero MAX_STREAMS for client-initiated bidirectional
streams after receiving an appropriate SETTINGS frame from the
server.
Draft: draft-ietf-webtrans-http3

Commentary: The H3 draft is light on error handling guidance . There are number of cases for bad session IDs : session ID is not a client initiated bidirectional stream ID session ID refers to a stream that did not perform a WebTransport handshake session ID refers to a stream that has been closed or reset Presumably there is no error when a DATAGRAM arrives with a bad session i d -- you just drop it ? For streams , perhaps HTTPIDERROR is appropriate ? Issues and both refer to cases where you receive a session ID that has not been created yet . Best to keep the discussion there , but it 's likely we want to allow clients / servers to buffer some of these at their own discretion rather than require an error . 
 For 1 , I think it should be an error . For 2 , we may want to clarify that the headers should be already known at that point , but it should be an error . For 3 , I am not sure how to enforce this without running into potential race conditions , so we may want to leave those as - is . As for the datagrams , I think h3 - datagram draft should handle this . 
 Thinking about 2 more , I think there 's also a race condition in which a data stream could be received between the stream being open and headers being processed . I 'll write up a PR for 1 . 
 I think for 2 , I meant the ID refers to a stream where the headers were known but it was not a CONNECT stream . 
 Discussed at IETF 111 . Sense of the room for MUST close for 1 , MAY close in other scenarios .
If at any point a session ID is received that cannot a valid ID for a
client-initiated bidirectional stream, the recepient MUST close the
connection with an H3_ID_ERROR error code.