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

Commentary: cc who pointed out to me we never specified the allowed value range
In order to indicate support for WebTransport, both the client and
the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1"
in their SETTINGS frame.  Endpoints MUST NOT use any WebTransport-
related functionality unless the parameter has been negotiated.
In order to indicate support for WebTransport, both the client and
the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1"
in their SETTINGS frame.  The SETTINGS_ENABLE_WEBTRANSPORT parameter
value SHALL be either "0" or "1", with "0" being the default; an
endpoint that receives a value other than "0" or "1" MUST close the
connection with the H3_SETTINGS_ERROR error code.  Endpoints MUST NOT
use any WebTransport-related functionality unless the parameter has
been negotiated.
Draft: draft-vvv-webtransport-http3

Commentary: This defines a new URL scheme for QuicTransport , and clarifies the use of "  " for Http3Transport .
As Http3Transport sessions are established over HTTP/3, they are
identified using the "https" URI scheme RFC7230.
A transport protocol (WebTransprot protocol in context where this
might be ambiguos) is a protocol that can be used to back a
transport on the wire.  It can provide the transport features
described in this document, and is expected to fulfill all of the
requirements described herein.
A transport protocol (WebTransport protocol in context where this
might be ambiguos) is a protocol that can be used to back a
transport on the wire.  It can provide the transport features
described in this document, and is expected to fulfill all of the
requirements described herein.
Any transport protocol used MUST provide a way for a server endpoint
location to be described using a URI RFC3986.  They can be used for
integration with various Web platform features that represent
resources as URIs, such as Content Security Policy CSP.
NOTE: the URI scheme defintion in this section is provisional and
subject to change, especially the name of the scheme.
QuicTransport uses the "quic-transport" URI scheme for identifying
QuicTransport servers.
This document does not define any semantics to "path-abempty",
"query" or "fragment" portions of the URI, nor does it delegate those
to the host owners.  Any QuicTransport implementation MUST ignore
those until a subsequent specification assigns semantics to those.
The "host" component MUST NOT be empty.  If the "port" component is
missing, the port SHALL be assumed to be 0.
NOTE: this effectively requires the port number to be specified.
This specification may include an actually usable default port number
in the future.
In order to connect to a QuicTransport server identified by a given
URI, the user agent SHALL establish a QUIC connection to the
specified "host" and "port" as described in connection.  It MUST
immediately signal an error to the client if the port value is 0.
This document contains the request for the registration of the URI
scheme "quic-transport".  The registration request is in accordance
with RFC7595.
uri of this document.