Draft: draft-webtransport-http2

Commentary: Merging so we can upload , please do leave any comments if you find some and/or file issues !
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.
Following the establishment of a WebTransport Connect stream, either
the client or the server can initiate a WebTransport Stream by
sending the WTHEADERS frame, defined in 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.
Clients or servers use a WTHEADERS frame to initate a new
WebTransport Stream.
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.
Upon receipt of SETTINGS_ENABLE_WEBTRANSPORT with a value of 1, an
endpoint MAY use the WTHEADERS frame type defined in this document.
An endpoint that supports receiving the WTHEADERS as part of the
WebTransport protocol SHOULD send this setting with a value of 1.
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.
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.
Upon receipt of SETTINGS_ENABLE_WEBTRANSPORT with a value of 1, an
endpoint MAY use the "WTHEADERS" frame type defined in this document.
An endpoint that supports receiving the "WTHEADERS" as part of the
WebTransport protocol SHOULD send this setting with a value of 1.
If the response to the extended CONNECT request indicates success of
the handshake, then all further data sent or received on the new
HTTP/2 stream is considered to be that of the WebTransport protocol
and follows the semantics defined by that protocol.
If the response to the extended CONNECT request indicates success of
the handshake, then all further data sent or received on the new
HTTP/2 stream is considered to be that of the WebTransport protocol
and follows the semantics defined by that protocol.  If the response
indicates failure of the handshake, any WebTransport Streams that
reference the WebTransport Connect Stream that failed to establish
MUST also be reset.
Once the extended CONNECT handshake has completed and a WebTransport
connect stream has been established, WTHEADERS frames can be sent
that reference that stream in the Connect Stream ID field to
establish WebTransport Streams.  WebTransport Connect Streams are
intended for exchanging metadata only and are best treated as long
lived streams.  Once a WebTransport Connect Stream is closed, all
routing information it carries is lost, and subsequent WebTransport
Streams cannot be created with WTHEADERS frames until the client
completes another extended CONNECT handshake to establish a new
WebTransport Connect Stream.
Once the extended CONNECT handshake has completed and a WebTransport
connect stream has been established, WTHEADERS frames can be sent
that reference that stream in the Connect Stream ID field to
establish WebTransport Streams.  WebTransport Connect Streams are
intended for exchanging metadata only and are RECOMMENDED to be long
lived streams.  Once a WebTransport Connect Stream is closed, all
routing information it carries is lost, and subsequent WebTransport
Streams cannot be created with WTHEADERS frames until the client
completes another extended CONNECT handshake to establish a new
WebTransport Connect Stream.
An endpoint MUST NOT send data on a WebTransport Connect Stream
beyond the completion of the extended CONNECT handshake.  If data is
received by an endpoint on a WebTransport Connect Stream, it MUST
reset that stream with a new error code, PROHIBITED_WT_CONNECT_DATA,
indicating that additional data is prohibited on the Connect Stream
when using "webtransport" as the ":protocol" value.
An endpoint MUST NOT send DATA frames with a non-zero payload length
on a WebTransport Connect Stream beyond the completion of the
extended CONNECT handshake.  If data is received by an endpoint on a
WebTransport Connect Stream, it MUST reset that stream with a new
error code, PROHIBITED_WT_CONNECT_DATA, indicating that additional
data is prohibited on the Connect Stream when using "webtransport" as
the ":protocol" value.
Endpoints SHOULD refresh any timeout on the Connect Stream while its
associated WebTransport Streams are expected to remain open.  For
example, an endpoint might choose to refresh a timeout on a Connect
Stream any time a corresponding timeout is refreshed on a
corresponding WebTransport Stream, such as when any data is sent or
received on that WebTransport Stream.
Endpoints SHOULD take measures to prevent a peer or intermediary from
timing out the Connect Stream while its associated WebTransport
Streams are expected to remain open.  For example, an endpoint might
choose to refresh a timeout on a Connect Stream any time a
corresponding timeout is refreshed on a corresponding WebTransport
Stream, such as when any data is sent or received on that
WebTransport Stream.
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.  However, for
stream priority and dependencies, WebTransport Streams have one
additional constraint: a WebTransport Streams can only have a
dependency on its Connect Stream, or any WebTransport Streams that
also references the same Connect Stream.  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
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.
Any segment on which SETTINGS_ENABLE_WEBTRANSPORT has been negotiated
MUST route all WebTransport Streams established by WTHEADERS frames
identically to their corresponding WebTransport Connect Streams.
If an intermediary cannot route WebTransport Streams on a subsequent
segment of the path, it can fail the extended CONNECT handshake and
prevent a WebTransport Connect Stream from being established for a
given endpoint.
Any segment on which SETTINGS_ENABLE_WEBTRANSPORT has been negotiated
MUST route all WebTransport Streams established by WTHEADERS frames
on the same connection as their corresponding WebTransport Connect
Streams.
If an intermediary cannot route WebTransport Streams on a subsequent
segment of the path, it can fail the extended CONNECT handshake and
prevent a WebTransport Connect Stream from being established for a
given endpoint.  In the event that additional WebTransport Streams
reference that WebTransport Connect Stream, they will also be reset.
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,
as well as the security properties of client-server communication via
HTTP/2 as described in RFC7540.
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,
as well as the security properties of client-server communication via
HTTP/2 as described in RFC7540.