Draft: draft-kinnear-webtransport-http2

Commentary: Move some text out of the introduction into the overview , fix a bunch of typos , and clean up some of the language to aid in clarity of upcoming sections of text .
WebTransport 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
Http2Transport, a WebTransport protocol that is based on HTTP/2 and
provides support for bidirectional streams multiplexed within the
same HTTP/2 connection.
WebTransport 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
Http2Transport, a WebTransport protocol that is based on HTTP/2 and
provides support for either endpoint to initiate streams multiplexed
within the same HTTP/2 connection.
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.
Http2Transport introduces a new HTTP/2 frame which carries structured
metadata like the HEADERS and PUSH_PROMISE frames but without the
constraints of the request/response state machine and semantics.
Allows WebTransport streams to take advantage of HTTP/2 features
such as header compression, prioritization and flow-control.
Allows WebTransport streams to take advantage of HTTP/2 features
such as header compression, prioritization, and flow-control.
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.
Clients negotiate the use of WebTransport over HTTP/2 using both the
SETTINGS frame and one or more extended CONNECT requests as defined
in RFC8441.
The extended CONNECT method extension uses the ":protocol" psuedo-
header field to negotiate the protocol that will be used on a given
stream in an HTTP/2 connection.  This document registers a new token,
"webtransport", in the "Hypertext Transfer Protocol (HTTP) Upgrade
Token Registry" established by RFC7230 and located at
https://www.iana.org/assignments/http-upgrade-tokens/ [1].
This token is used in the ":protocol" psuedo-header field to indicate
that the endpoint wishes to use the WebTransport protocol on the new
stream.
The extended CONNECT method extension uses the ":protocol" pseudo-
header field to negotiate the protocol that will be used on a given
stream in an HTTP/2 connection.  This document registers a new token,
"webtransport", in the "Hypertext Transfer Protocol (HTTP) Upgrade
Token Registry" established by RFC7230 and located at
https://www.iana.org/assignments/http-upgrade-tokens/ [1].
This token is used in the ":protocol" pseudo-header field to indicate
that the endpoint wishes to use the WebTransport protocol on the new
stream.
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 WebTransport Connect Stream on which the
WebTransport protocol was negotiated.
A new HTTP/2 frame called WTHEADERS is introduced for either endpoint
to establish streams.  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 WebTransport Connect Stream on which the WebTransport
protocol was negotiated.
An endpoint that wishes to establish a WebTransport session over an
HTTP/2 stream follows the extended CONNECT handshake procedure
defined in RFC8441, specifying "webtransport" for the :protocol
psuedo-header field.
The :scheme and :path psuedo-headers are required by RFC6455.  The
scheme of the target URI MUST be set to "https" for all :protocol
values.  The path is used to identify the specific WebTransport
server instance for negotiation and MAY be set to "/" (an empty path
component).
An endpoint that wishes to establish a WebTransport session over an
HTTP/2 stream follows the extended CONNECT handshake procedure
defined in RFC8441, specifying "webtransport" for the :protocol
pseudo-header field.
The :scheme and :path pseudo-headers are required by RFC6455.  The
scheme of the target URI MUST be set to "https" for all :protocol
values.  The path is used to identify the specific WebTransport
server instance for negotiation and MAY be set to "/" (an empty path
component).
WebTransport Connect Streams are regular HTTP/2 streams that follow
the stream lifecycle descirbed in Section 5.1 of RFC7540.
WebTransport Streams established with the WTHEADERS frame also follow
the same lifecycle as regular HTTP/2 streams, but have an additional
dependency on the Connect Stream that they reference via their
Connect Stream ID.
WebTransport Connect Streams are regular HTTP/2 streams that follow
the stream lifecycle described in Section 5.1 of RFC7540.
WebTransport Streams established with the WTHEADERS frame also follow
the same lifecycle as regular HTTP/2 streams, but have an additional
dependency on the Connect Stream that they reference via their
Connect Stream ID.
WebTransport Streams are extended HTTP/2 streams, and all of the
standard HTTP/2 features for streams still apply to WebTransport
Streams.  For example, WebTransport Streams are counted against the
concurrent stream limit, which is defined in Section 5.1.2 of
RFC7540.  The connection level and stream level flow control
principles are still valid for WebTransport Streams.  Prioritizing
the WebTransport Streams across different Connect Stream groupings
does not make sense because they belong to different services.
WebTransport Streams are extended HTTP/2 streams, and all of the
standard HTTP/2 features for streams still apply to WebTransport
Streams.  For example, WebTransport Streams are counted against the
concurrent stream limit, which is defined in Section 5.1.2 of
RFC7540.  The connection level and stream level flow control limits
are still valid for WebTransport Streams.  Prioritizing the
WebTransport Streams across different Connect Stream groupings does
not make sense because they belong to different services.
WebTransport Connect Streams, and their corresponding WebTransport
Streams, can be independently routed by intermediaries on the network
path.  The main purpose for a WebTransport Connect Stream is to
facilitate imtermediary traversal by WebTransport Streams.
WebTransport Connect Streams, and their corresponding WebTransport
Streams, can be independently routed by intermediaries on the network
path.  The main purpose for a WebTransport Connect Stream is to
facilitate intermediary traversal by WebTransport Streams.