< draft-ietf-webtrans-http2-00.txt   draft-ietf-webtrans-http2-01.txt >
webtrans A. Frindell webtrans A. Frindell
Internet-Draft Facebook Inc. Internet-Draft Facebook Inc.
Intended status: Standards Track E. Kinnear Intended status: Standards Track E. Kinnear
Expires: 3 January 2022 T. Pauly Expires: 31 January 2022 T. Pauly
Apple Inc. Apple Inc.
V. Vasiliev V. Vasiliev
Google Google
G. Xie G. Xie
Facebook Inc. Facebook Inc.
2 July 2021 30 July 2021
WebTransport using HTTP/2 WebTransport using HTTP/2
draft-ietf-webtrans-http2-00 draft-ietf-webtrans-http2-01
Abstract Abstract
WebTransport [OVERVIEW] is a protocol framework that enables clients WebTransport [OVERVIEW] is a protocol framework that enables clients
constrained by the Web security model to communicate with a remote constrained by the Web security model to communicate with a remote
server using a secure multiplexed transport. This document describes server using a secure multiplexed transport. This document describes
a WebTransport protocol that is based on HTTP/2 [RFC7540] and a WebTransport protocol that is based on HTTP/2 [RFC7540] and
provides support for unidirectional streams, bidirectional streams provides support for unidirectional streams, bidirectional streams
and datagrams, all multiplexed within the same HTTP/2 connection. and datagrams, all multiplexed within the same HTTP/2 connection.
Note to Readers Note to Readers
Discussion of this draft takes place on the WebTransport mailing list Discussion of this draft takes place on the WebTransport mailing list
(webtransport@ietf.org), which is archived at (webtransport@ietf.org (mailto:webtransport@ietf.org)), which is
<https://mailarchive.ietf.org/arch/search/?email_list=webtransport>. archived at https://mailarchive.ietf.org/arch/
search/?email_list=webtransport.
The repository tracking the issues for this draft can be found at The repository tracking the issues for this draft can be found at
<https://github.com/ietf-wg-webtrans/draft-webtransport-http2>. The https://github.com/ietf-wg-webtrans/draft-webtransport-http2. The
web API draft corresponding to this document can be found at web API draft corresponding to this document can be found at
<https://w3c.github.io/webtransport/>. https://w3c.github.io/webtransport/.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 January 2022. This Internet-Draft will expire on 31 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 38 skipping to change at page 2, line 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. Session Establishment . . . . . . . . . . . . . . . . . . . . 4 3. Session Establishment . . . . . . . . . . . . . . . . . . . . 4
3.1. Establishing a Transport-Capable HTTP/2 Connection . . . 4 3.1. Establishing a Transport-Capable HTTP/2 Connection . . . 4
3.2. Extended CONNECT in HTTP/2 . . . . . . . . . . . . . . . 4 3.2. Extended CONNECT in HTTP/2 . . . . . . . . . . . . . . . 4
3.3. Creating a New Session . . . . . . . . . . . . . . . . . 4 3.3. Creating a New Session . . . . . . . . . . . . . . . . . 4
3.4. Limiting the Number of Simultaneous Sessions . . . . . . 5 3.4. Limiting the Number of Simultaneous Sessions . . . . . . 5
4. WebTransport Features . . . . . . . . . . . . . . . . . . . . 5 4. WebTransport Features . . . . . . . . . . . . . . . . . . . . 5
4.1. WT_STREAM Frame . . . . . . . . . . . . . . . . . . . . . 6 4.1. WT_STREAM Frame . . . . . . . . . . . . . . . . . . . . . 6
4.2. WT_DATAGRAM Frame . . . . . . . . . . . . . . . . . . . . 7 4.2. WT_RST_STREAM Frame . . . . . . . . . . . . . . . . . . . 7
5. Session Termination . . . . . . . . . . . . . . . . . . . . . 8 4.3. WT_STOP_SENDING Frame . . . . . . . . . . . . . . . . . . 8
6. Transport Properties . . . . . . . . . . . . . . . . . . . . 8 4.4. WT_DATAGRAM Frame . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Session Termination . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Transport Properties . . . . . . . . . . . . . . . . . . . . 11
8.1. HTTP/2 SETTINGS Parameter Registration . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.2. Frame Type Registration . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.3. HTTP/2 Error Code Registry . . . . . . . . . . . . . . . 10 8.1. HTTP/2 SETTINGS Parameter Registration . . . . . . . . . 12
8.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Frame Type Registration . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3. HTTP/2 Error Code Registry . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Currently, the only mechanism in HTTP/2 for server to client Currently, the only mechanism in HTTP/2 for server to client
communication is server push. That is, servers can initiate communication is server push. That is, servers can initiate
unidirectional push promised streams to clients, but clients cannot unidirectional push promised streams to clients, but clients cannot
respond to them; they can only accept them or discard them. respond to them; they can only accept them or discard them.
Additionally, intermediaries along the path may have different server Additionally, intermediaries along the path may have different server
push policies and may not forward push promised streams to the push policies and may not forward push promised streams to the
downstream client. This best effort mechanism is not sufficient to downstream client. This best effort mechanism is not sufficient to
skipping to change at page 3, line 46 skipping to change at page 3, line 47
This document follows terminology defined in Section 1.2 of This document follows terminology defined in Section 1.2 of
[OVERVIEW]. Note that this document distinguishes between a [OVERVIEW]. Note that this document distinguishes between a
WebTransport server and an HTTP/2 server. An HTTP/2 server is the WebTransport server and an HTTP/2 server. An HTTP/2 server is the
server that terminates HTTP/2 connections; a WebTransport server is server that terminates HTTP/2 connections; a WebTransport server is
an application that accepts WebTransport sessions, which can be an application that accepts WebTransport sessions, which can be
accessed via an HTTP/2 server. accessed via an HTTP/2 server.
2. Protocol Overview 2. Protocol Overview
WebTransport servers are identified by a pair of authority value and WebTransport servers are identified by an HTTPS URI as defined in
path value (defined in [RFC3986] Sections 3.2 and 3.3 Section 4.2.2 of [HTTP].
correspondingly).
When an HTTP/2 connection is established, both the client and server When an HTTP/2 connection is established, both the client and server
have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to
indicate that they both support WebTransport over HTTP/2. indicate that they both support WebTransport over HTTP/2.
WebTransport sessions are initiated inside a given HTTP/2 connection WebTransport sessions are initiated inside a given HTTP/2 connection
by the client, who sends an extended CONNECT request [RFC8441]. If by the client, who sends an extended CONNECT request [RFC8441]. If
the server accepts the request, an WebTransport session is the server accepts the request, an WebTransport session is
established. The resulting stream will be further referred to as a established. The resulting stream will be further referred to as a
_CONNECT stream_, and its stream ID is used to uniquely identify a _CONNECT stream_, and its stream ID is used to uniquely identify a
skipping to change at page 4, line 51 skipping to change at page 5, line 7
SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT
setting implies that an endpoint supports extended CONNECT. setting implies that an endpoint supports extended CONNECT.
3.3. Creating a New Session 3.3. Creating a New Session
As WebTransport sessions are established over HTTP/2, they are As WebTransport sessions are established over HTTP/2, they are
identified using the "https" URI scheme [RFC7230]. identified using the "https" URI scheme [RFC7230].
In order to create a new WebTransport session, a client can send an In order to create a new WebTransport session, a client can send an
HTTP CONNECT request. The ":protocol" pseudo-header field HTTP CONNECT request. The ":protocol" pseudo-header field
([RFC8441]) MUST be set to "webtransport" (Section 7.1 ([RFC8441]) MUST be set to "webtransport" (Section 7.1 of
[WEBTRANSPORT-H3]). The ":scheme" field MUST be "https". Both the [WEBTRANSPORT-H3]). The ":scheme" field MUST be "https". Both the
":authority" and the ":path" value MUST be set; those fields indicate ":authority" and the ":path" value MUST be set; those fields indicate
the desired WebTransport server. An "Origin" header [RFC6454] MUST the desired WebTransport server. An "Origin" header [RFC6454] MUST
be provided within the request. be provided within the request.
Upon receiving an extended CONNECT request with a ":protocol" field Upon receiving an extended CONNECT request with a ":protocol" field
set to "webtransport", the HTTP/2 server can check if it has a set to "webtransport", the HTTP/2 server can check if it has a
WebTransport server associated with the specified ":authority" and WebTransport server associated with the specified ":authority" and
":path" values. If it does not, it SHOULD reply with status code 404 ":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 (Section 6.5.4, [RFC7231]). If it does, it MAY accept the session by
skipping to change at page 7, line 5 skipping to change at page 7, line 11
As with all HTTP/2 streams, WebTransport streams initiated by a As with all HTTP/2 streams, WebTransport streams initiated by a
client have odd stream IDs and those initiated by a server have even client have odd stream IDs and those initiated by a server have even
stream IDs. stream IDs.
The recipient MUST respond with a stream error of type The recipient MUST respond with a stream error of type
WT_STREAM_ERROR if the specified WebTransport Connect Stream does not WT_STREAM_ERROR if the specified WebTransport Connect Stream does not
exist, is not a stream established via extended CONNECT to use the exist, is not a stream established via extended CONNECT to use the
"webtransport" protocol, or if it is in the "closed" or "half-closed "webtransport" protocol, or if it is in the "closed" or "half-closed
(remote)" stream state. (remote)" stream state.
4.2. WT_DATAGRAM Frame 4.2. WT_RST_STREAM Frame
The RST_STREAM frame defined in HTTP/2 moves a stream to the "closed"
state, but WebTransport streams can be reset unidirectionally, as in
QUIC and HTTP/3. A new HTTP/2 frame called WT_RST_STREAM is
introduced for an endpoint to unidirectionally reset a stream for
writing. WT_RST_STREAM frames can be sent on a stream in the "open",
or "half-closed (remote)" state.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
| Error Code (32) |
+---------------------------------------------------------------+
Figure 2: WT_RST_STREAM Frame Format
The WT_RST_STREAM frame contains a single unsigned, 32-bit integer
identifying the error code. The error code indicates why the stream
is being abruptly terminated for writing.
The WT_RST_STREAM frame does not define any flags.
The WT_RST_STREAM frame half-closes the referenced stream and effects
the same state machine transitions as sending or receiving the
END_STREAM flag. If the sender is in the "open" state, it
transitions to "half-closed (local)". If the sender is in the "half-
closed (remote)" state, it transitions to "closed". If the receiver
is in the "open" state, it transitions to "half-closed (remote)". If
the receiver is in the "half-closed (local)" state, it transitions to
"closed".
After sending a WT_RST_STREAM on a stream, the sender MUST NOT send
additional DATA frames for that stream. If another frame is received
on a stream after receiving a WT_RST_STREAM, the recipient MUST treat
this as a connection error of type PROTOCOL_ERROR.
WT_RST_STREAM frames MUST be associated with a WebTransport stream.
If a WT_RST_STREAM frame is received with a stream identifier of 0x0,
or a request or push stream, the recipient MUST treat this as a
connection error of type PROTOCOL_ERROR.
WT_RST_STREAM frames MUST NOT be sent for a stream in any state other
than "open" or "half-closed (remote)". If a WT_RST_STREAM frame
identifying a stream in the "idle", "reserved (local)", "reserved
(remote)" state is received, the recipient MUST treat this as a
connection error (Section 5.4.1) of type PROTOCOL_ERROR. Because of
race conditions with WT_STOP_SENDING, it is possible to receive a
WT_RST_STREAM in the "half-closed (remote)" or "closed" state. The
recipient should ignore the frame in this case.
A WT_RST_STREAM frame with a length other than 4 octets MUST be
treated as a connection error (Section 5.4.1) of type
FRAME_SIZE_ERROR.
4.3. WT_STOP_SENDING Frame
The RST_STREAM frame defined in HTTP/2 moves a stream to the "closed"
state, but WebTransport streams can be reset unidirectionally, as in
QUIC and HTTP/3. A new HTTP/2 frame called WT_STOP_SENDING is
introduced for an endpoint to unidirectionally reset a stream for
reading. WT_STOP_SENDING frames can be sent on a stream in the
"open", or "half-closed (local)" state.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
| Error Code (32) |
+---------------------------------------------------------------+
Figure 3: WT_STOP_SENDING Frame Format
The WT_STOP_SENDING frame contains a single unsigned, 32-bit integer
identifying the error code. The error code indicates why the reading
the stream is being abandoned.
The WT_STOP_SENDING frame does not define any flags.
The WT_STOP_SENDING frame half-closes the referenced stream and
effects the same state machine transitions as sending or receiving
the END_STREAM flag. If the sender is in the open state, it
transitions to "half-closed (remote)". If the sender is in the
"half-closed (local)" state, it transitions to "closed". If the
receiver is in the "open" state, it transitions to "half-closed
(local)". If the receiver is in the "half-closed (remote)" state, it
transitions to "closed".
After receiving a WT_STOP_SENDING on a stream, the sender MUST NOT
send additional frames for that stream. After sending the
WT_STOP_SENDING, the sending endpoint MUST be prepared to receive and
handle additional frames sent on the stream that might have been sent
by the peer prior to the arrival of the WT_STOP_SENDING.
WT_STOP_SENDING frames MUST be associated with a WebTransport stream.
If a WT_STOP_SENDING frame is received with a stream identifier of
0x0, or a request or push stream, the recipient MUST treat this as a
connection error of type PROTOCOL_ERROR.
WT_STOP_SENDING frames MUST NOT be sent for a stream in any state
other than "open" or "half-closed (local)". It is possible to
receive a WT_STOP_SENDING in another state however, because the
sender might have closed or reset the stream while the
WT_STOP_SENDING was in flight. If a WT_STOP_SENDING frame
identifying a stream that is already "closed" or "half-closed
(local)", the recipient SHOULD ignore the frame.
It is also possible to receive DATA frames on a WebTransport stream
in the "half-closed (remote)" or "closed" states if the stream
transitioned there via WT_STOP_SENDING. If a DATA frame is received
on a WebTransport stream in one of these states, the recipient MUST
account for its contribution against the connection flow-control
window and MUST NOT treat it as an error.
A WT_STOP_SENDING frame with a length other than 4 octets MUST be
treated as a connection error (Section 5.4.1) of type
FRAME_SIZE_ERROR.
4.4. WT_DATAGRAM Frame
A new HTTP/2 frame called WT_DATAGRAM is introduced for either A new HTTP/2 frame called WT_DATAGRAM is introduced for either
endpoint to transmit a datagram. WT_DATAGRAM frames are sent with endpoint to transmit a datagram. WT_DATAGRAM frames are sent with
Stream Identifier 0. Stream Identifier 0.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+ +---------------+
|Pad Length? (8)| |Pad Length? (8)|
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
|R| Session ID (31) | |R| Session ID (31) |
+-+-------------------------------------------------------------+ +-+-------------------------------------------------------------+
| Data (*) ... | Data (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| Padding (*) ... | Padding (*) ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 4: WT_DATAGRAM Frame Format
Figure 2: WT_DATAGRAM Frame Format
The WT_DATAGRAM frame define the following fields: The WT_DATAGRAM frame define the following fields:
Pad Length: An 8-bit field containing the length of the frame padding Pad Length: An 8-bit field containing the length of the frame padding
in units of octets. This field is conditional (as signified by a "?" in units of octets. This field is conditional (as signified by a "?"
in the diagram) and is only present if the PADDED flag is set. in the diagram) and is only present if the PADDED flag is set.
Session ID: An unsigned 31-bit integer that identifies the stream Session ID: An unsigned 31-bit integer that identifies the stream
Connect Stream for this Web Transport stream. The Session ID MUST be Connect Stream for this Web Transport stream. The Session ID MUST be
MUST be an open stream negotiated via the extended CONNECT protocol MUST be an open stream negotiated via the extended CONNECT protocol
skipping to change at page 10, line 14 skipping to change at page 12, line 43
The "WT_STREAM" frame allows HTTP/2 client- and server-initiated The "WT_STREAM" frame allows HTTP/2 client- and server-initiated
unidirectional and bidirectional streams to be used by WebTransport: unidirectional and bidirectional streams to be used by WebTransport:
Code: 0xTBD Code: 0xTBD
Frame Type: WEBTRANSPORT_STREAM Frame Type: WEBTRANSPORT_STREAM
Specification: This document Specification: This document
The "WT_RST_STREAM" frame allows HTTP/2 WebTransport streams to be
unidirectionally reset for writing:
Code: 0xTBD
Frame Type: WEBTRANSPORT_RST_STREAM
Specification: This document
The "WT_STOP_SENDING" frame allows HTTP/2 WebTransport streams to be
unidirectionally reset for reading:
Code: 0xTBD
Frame Type: WEBTRANSPORT_STOP_SENDING
Specification: This document
The "WT_DATAGRAM" frame allows HTTP/2 client and server to exchange The "WT_DATAGRAM" frame allows HTTP/2 client and server to exchange
datagrams used by WebTransport: datagrams used by WebTransport:
Code: 0xTBD Code: 0xTBD
Frame Type: WEBTRANSPORT_DATAGRAM Frame Type: WEBTRANSPORT_DATAGRAM
Specification: This document Specification: This document
8.3. HTTP/2 Error Code Registry 8.3. HTTP/2 Error Code Registry
skipping to change at page 12, line 45 skipping to change at page 15, line 45
WebTransport Data WebTransport Data
DATA + END_STREAM DATA + END_STREAM
Stream ID = 2 Stream ID = 2
WebTransport Data WebTransport Data
9. References 9. References
9.1. Normative References 9.1. Normative References
[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-17, 25 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
semantics-17>.
[OVERVIEW] Vasiliev, V., "The WebTransport Protocol Framework", Work [OVERVIEW] Vasiliev, V., "The WebTransport Protocol Framework", Work
in Progress, Internet-Draft, draft-ietf-webtrans-overview- in Progress, Internet-Draft, draft-ietf-webtrans-overview-
latest, <https://datatracker.ietf.org/doc/html/draft-ietf- 02, 28 July 2021, <https://datatracker.ietf.org/doc/html/
webtrans-overview-latest>. draft-ietf-webtrans-overview-02>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/rfc/rfc6454>. <https://www.rfc-editor.org/rfc/rfc6454>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/rfc/rfc6585>. <https://www.rfc-editor.org/rfc/rfc6585>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
skipping to change at page 13, line 48 skipping to change at page 16, line 48
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, September 2018, RFC 8441, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/rfc/rfc8441>. <https://www.rfc-editor.org/rfc/rfc8441>.
[WEBTRANSPORT-H3] [WEBTRANSPORT-H3]
Vasiliev, V., "WebTransport over HTTP/3", Work in Vasiliev, V., "WebTransport over HTTP/3", Work in
Progress, Internet-Draft, draft-ietf-webtrans- Progress, Internet-Draft, draft-ietf-webtrans-http3-01, 19
http3-latest, <https://datatracker.ietf.org/doc/html/ May 2021, <https://datatracker.ietf.org/doc/html/draft-
draft-ietf-webtrans-http3-latest>. ietf-webtrans-http3-01>.
9.2. Informative References 9.2. Informative References
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long "Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202, Polling and Streaming in Bidirectional HTTP", RFC 6202,
DOI 10.17487/RFC6202, April 2011, DOI 10.17487/RFC6202, April 2011,
<https://www.rfc-editor.org/rfc/rfc6202>. <https://www.rfc-editor.org/rfc/rfc6202>.
Acknowledgments Acknowledgments
 End of changes. 17 change blocks. 
39 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/