| < draft-ietf-masque-h3-datagram-08.txt | draft-ietf-masque-h3-datagram-09.txt > | |||
|---|---|---|---|---|
| MASQUE D. Schinazi | MASQUE D. Schinazi | |||
| Internet-Draft Google LLC | Internet-Draft Google LLC | |||
| Intended status: Standards Track L. Pardue | Intended status: Standards Track L. Pardue | |||
| Expires: 29 September 2022 Cloudflare | Expires: 13 October 2022 Cloudflare | |||
| 28 March 2022 | 11 April 2022 | |||
| HTTP Datagrams and the Capsule Protocol | HTTP Datagrams and the Capsule Protocol | |||
| draft-ietf-masque-h3-datagram-08 | draft-ietf-masque-h3-datagram-09 | |||
| Abstract | Abstract | |||
| This document describes HTTP Datagrams, a convention for conveying | This document describes HTTP Datagrams, a convention for conveying | |||
| multiplexed, potentially unreliable datagrams inside an HTTP | multiplexed, potentially unreliable datagrams inside an HTTP | |||
| connection. | connection. | |||
| In HTTP/3, HTTP Datagrams can be conveyed natively using the QUIC | In HTTP/3, HTTP Datagrams can be conveyed natively using the QUIC | |||
| DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or | DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or | |||
| undesirable, they can be sent using the Capsule Protocol, a more | undesirable, they can be sent using the Capsule Protocol, a more | |||
| general convention for conveying data in HTTP connections. | general convention for conveying data in HTTP connections. | |||
| Both are intended for use by HTTP extensions, not applications. | HTTP Datagrams and the Capsule Protocol are intended for use by HTTP | |||
| extensions, not applications. | ||||
| Discussion Venues | About This Document | |||
| This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
| Discussion of this document takes place on the MASQUE WG mailing list | The latest revision of this draft can be found at https://ietf-wg- | |||
| (masque@ietf.org), which is archived at | masque.github.io/draft-ietf-masque-h3-datagram/draft-ietf-masque- | |||
| h3-datagram.html. Status information for this document may be found | ||||
| at https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram/. | ||||
| Discussion of this document takes place on the MASQUE Working Group | ||||
| mailing list (mailto:masque@ietf.org), which is archived at | ||||
| https://mailarchive.ietf.org/arch/browse/masque/. | https://mailarchive.ietf.org/arch/browse/masque/. | |||
| Source for this draft and an issue tracker can be found at | Source for this draft and an issue tracker can be found at | |||
| https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram. | https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram. | |||
| 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 29 September 2022. | ||||
| This Internet-Draft will expire on 13 October 2022. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 26 ¶ | skipping to change at page 2, line 37 ¶ | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 | 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 | |||
| 2. HTTP Datagrams . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. HTTP Datagrams . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. HTTP/3 Datagrams . . . . . . . . . . . . . . . . . . . . 4 | 2.1. HTTP/3 Datagrams . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.1.1. The H3_DATAGRAM HTTP/3 SETTINGS Parameter . . . . . . 5 | 2.1.1. The SETTINGS_H3_DATAGRAM HTTP/3 Setting . . . . . . . 5 | |||
| 2.2. HTTP Datagrams using Capsules . . . . . . . . . . . . . . 6 | 2.2. HTTP Datagrams using Capsules . . . . . . . . . . . . . . 6 | |||
| 3. Capsules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Capsules . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 3.1. HTTP Data Streams . . . . . . . . . . . . . . . . . . . . 7 | 3.1. HTTP Data Streams . . . . . . . . . . . . . . . . . . . . 7 | |||
| 3.2. The Capsule Protocol . . . . . . . . . . . . . . . . . . 7 | 3.2. The Capsule Protocol . . . . . . . . . . . . . . . . . . 8 | |||
| 3.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 | 3.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.4. The Capsule-Protocol Header Field . . . . . . . . . . . . 9 | 3.4. The Capsule-Protocol Header Field . . . . . . . . . . . . 9 | |||
| 3.5. The DATAGRAM Capsule . . . . . . . . . . . . . . . . . . 9 | 3.5. The DATAGRAM Capsule . . . . . . . . . . . . . . . . . . 10 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.1. HTTP/3 SETTINGS Parameter . . . . . . . . . . . . . . . . 11 | 5.1. HTTP/3 Setting . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.2. HTTP/3 Error Code . . . . . . . . . . . . . . . . . . . . 12 | 5.2. HTTP/3 Error Code . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.3. HTTP Header Field Name . . . . . . . . . . . . . . . . . 12 | 5.3. HTTP Header Field Name . . . . . . . . . . . . . . . . . 12 | |||
| 5.4. Capsule Types . . . . . . . . . . . . . . . . . . . . . . 12 | 5.4. Capsule Types . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 14 | 6.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 1. Introduction | 1. Introduction | |||
| HTTP extensions sometimes need to access underlying transport | HTTP extensions sometimes need to access underlying transport | |||
| protocol features such as unreliable delivery (as offered by [DGRAM]) | protocol features such as unreliable delivery (as offered by [DGRAM]) | |||
| to enable desirable features like an unreliable version of the | to enable desirable features. For example, this could allow | |||
| CONNECT method, and unreliable delivery in WebSockets [RFC6455] (or | introducing an unreliable version of the CONNECT method, or adding | |||
| its successors). | unreliable delivery to WebSockets [RFC6455]. | |||
| In Section 2, this document describes HTTP Datagrams, a convention | In Section 2, this document describes HTTP Datagrams, a convention | |||
| that supports the bidirectional and possibly multiplexed exchange of | that supports the bidirectional and optionally multiplexed exchange | |||
| data inside an HTTP connection. While HTTP datagrams are associated | of data inside an HTTP connection. While HTTP datagrams are | |||
| with HTTP requests, they are not part of message content; instead, | associated with HTTP requests, they are not part of message content; | |||
| they are intended for use by HTTP extensions (such as the CONNECT | instead, they are intended for use by HTTP extensions (such as the | |||
| method), and are compatible with all versions of HTTP. When the | CONNECT method), and are compatible with all versions of HTTP. | |||
| underlying transport protocol supports unreliable delivery (such as | ||||
| when the QUIC DATAGRAM extension is available in HTTP/3), they can | When HTTP is running over a transport protocol that supports | |||
| use that capability. | unreliable delivery (such as when the QUIC DATAGRAM extension is | |||
| available to HTTP/3), HTTP Datagrams can use that capability. | ||||
| This document also describes the HTTP Capsule Protocol in Section 3, | This document also describes the HTTP Capsule Protocol in Section 3, | |||
| to allow conveyance of HTTP Datagrams when the QUIC DATAGRAM frame is | to allow conveyance of HTTP Datagrams using reliable delivery. This | |||
| unavailable or undesirable, such as when earlier versions of HTTP are | addresses HTTP/3 cases where use of the QUIC DATAGRAM frame is | |||
| in use. | unavailable or undesirable, or where the transport protocol only | |||
| provides reliable delivery, such as with HTTP/1 or HTTP/2 over TCP. | ||||
| 1.1. Conventions and Definitions | 1.1. Conventions and Definitions | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. HTTP Datagrams | 2. HTTP Datagrams | |||
| HTTP Datagrams are a convention for conveying bidirectional and | HTTP Datagrams are a convention for conveying bidirectional and | |||
| potentially unreliable datagrams inside an HTTP connection, with | potentially unreliable datagrams inside an HTTP connection, with | |||
| multiplexing when possible. All HTTP Datagrams are associated with | multiplexing when possible. All HTTP Datagrams are associated with | |||
| an HTTP request. | an HTTP request. | |||
| When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC | When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC | |||
| DATAGRAM frame can be used to achieve these goals, including | DATAGRAM frame can be used to achieve these goals, including | |||
| unreliable delivery; see Section 2.1. Negotiation is achieved using | unreliable delivery; see Section 2.1. Negotiating the use of QUIC | |||
| a setting; see Section 2.1.1. | DATAGRAM frames for HTTP Datagrams is achieved via the exchange of | |||
| HTTP/3 settings; see Section 2.1.1. | ||||
| When running over HTTP/2, demultiplexing is provided by the HTTP/2 | When running over HTTP/2, demultiplexing is provided by the HTTP/2 | |||
| framing layer, but unreliable delivery is unavailable. HTTP | framing layer, but unreliable delivery is unavailable. HTTP | |||
| Datagrams are negotiated and conveyed using the Capsule Protocol; see | Datagrams are negotiated and conveyed using the Capsule Protocol; see | |||
| Section 3.5. | Section 3.5. | |||
| When running over HTTP/1, requests are strictly serialized in the | When running over HTTP/1, requests are strictly serialized in the | |||
| connection, and therefore demultiplexing is not available. | connection, and therefore demultiplexing is not available. | |||
| Unreliable delivery is likewise not available. HTTP Datagrams are | Unreliable delivery is likewise not available. HTTP Datagrams are | |||
| negotiated and conveyed using the Capsule Protocol; see Section 3.5. | negotiated and conveyed using the Capsule Protocol; see Section 3.5. | |||
| HTTP Datagrams MUST only be sent with an association to a stream | HTTP Datagrams MUST only be sent with an association to an HTTP | |||
| whose HTTP semantics explicitly supports HTTP Datagrams. For | request that explicitly supports them. For example, existing HTTP | |||
| example, existing HTTP methods GET and POST do not define semantics | methods GET and POST do not define semantics for associated HTTP | |||
| for associated HTTP Datagrams; therefore, HTTP Datagrams cannot be | Datagrams; therefore, HTTP Datagrams cannot be sent associated with | |||
| sent associated with GET or POST request streams. | GET or POST request streams. | |||
| If an HTTP Datagram associated with a method that has no known | If an HTTP Datagram is received and it is associated with a request | |||
| semantics for HTTP Datagrams is received, the receiver MUST abort the | that has no known semantics for HTTP Datagrams, the receiver MUST | |||
| corresponding stream; if HTTP/3 is in use, the stream MUST be aborted | terminate the request; if HTTP/3 is in use, the request stream MUST | |||
| with H3_DATAGRAM_ERROR. HTTP extensions can override these | be aborted with H3_DATAGRAM_ERROR (0x33). HTTP extensions can | |||
| requirements by defining a negotiation mechanism and semantics for | override these requirements by defining a negotiation mechanism and | |||
| HTTP Datagrams. | semantics for HTTP Datagrams. | |||
| 2.1. HTTP/3 Datagrams | 2.1. HTTP/3 Datagrams | |||
| When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM | When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM | |||
| frames uses the following format (using the notation from the | frames uses the following format (using the notation from the | |||
| "Notational Conventions" section of [QUIC]): | "Notational Conventions" section of [QUIC]): | |||
| HTTP/3 Datagram { | HTTP/3 Datagram { | |||
| Quarter Stream ID (i), | Quarter Stream ID (i), | |||
| HTTP Datagram Payload (..), | HTTP Datagram Payload (..), | |||
| skipping to change at page 4, line 44 ¶ | skipping to change at page 5, line 6 ¶ | |||
| Figure 1: HTTP/3 Datagram Format | Figure 1: HTTP/3 Datagram Format | |||
| Quarter Stream ID: A variable-length integer that contains the value | Quarter Stream ID: A variable-length integer that contains the value | |||
| of the client-initiated bidirectional stream that this datagram is | of the client-initiated bidirectional stream that this datagram is | |||
| associated with, divided by four (the division by four stems from | associated with, divided by four (the division by four stems from | |||
| the fact that HTTP requests are sent on client-initiated | the fact that HTTP requests are sent on client-initiated | |||
| bidirectional streams, and those have stream IDs that are | bidirectional streams, and those have stream IDs that are | |||
| divisible by four). The largest legal QUIC stream ID value is | divisible by four). The largest legal QUIC stream ID value is | |||
| 2^62-1, so the largest legal value of Quarter Stream ID is 2^60-1. | 2^62-1, so the largest legal value of Quarter Stream ID is 2^60-1. | |||
| Receipt of an HTTP/3 Datagram that includes a larger value MUST be | Receipt of an HTTP/3 Datagram that includes a larger value MUST be | |||
| treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR. | treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR | |||
| (0x33). | ||||
| HTTP Datagram Payload: The payload of the datagram, whose semantics | HTTP Datagram Payload: The payload of the datagram, whose semantics | |||
| are defined by the extension that is using HTTP Datagrams. Note | are defined by the extension that is using HTTP Datagrams. Note | |||
| that this field can be empty. | that this field can be empty. | |||
| Receipt of a QUIC DATAGRAM frame whose payload is too short to allow | Receipt of a QUIC DATAGRAM frame whose payload is too short to allow | |||
| parsing the Quarter Stream ID field MUST be treated as an HTTP/3 | parsing the Quarter Stream ID field MUST be treated as an HTTP/3 | |||
| connection error of type H3_DATAGRAM_ERROR. | connection error of type H3_DATAGRAM_ERROR (0x33). | |||
| HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's | HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's | |||
| send side is open. Once the receive side of a stream is closed, | send side is open. If a datagram is received after the corresponding | |||
| incoming datagrams for this stream are no longer expected so related | stream's receive side is closed, the received datagrams MUST be | |||
| state can be released. State MAY be kept for a short time to account | silently dropped. | |||
| for reordering. Once the state is released, the received associated | ||||
| datagrams MUST be silently dropped. | ||||
| If an HTTP/3 datagram is received and its Quarter Stream ID maps to a | If an HTTP/3 datagram is received and its Quarter Stream ID maps to a | |||
| stream that has not yet been created, the receiver SHALL either drop | stream that has not yet been created, the receiver SHALL either drop | |||
| that datagram silently or buffer it temporarily (on the order of a | that datagram silently or buffer it temporarily (on the order of a | |||
| round trip) while awaiting the creation of the corresponding stream. | round trip) while awaiting the creation of the corresponding stream. | |||
| If an HTTP/3 datagram is received and its Quarter Stream ID maps to a | If an HTTP/3 datagram is received and its Quarter Stream ID maps to a | |||
| stream that cannot be created due to client-initiated bidirectional | stream that cannot be created due to client-initiated bidirectional | |||
| stream limits, it SHOULD be treated as an HTTP/3 connection error of | stream limits, it SHOULD be treated as an HTTP/3 connection error of | |||
| type H3_ID_ERROR. Generating an error is not mandatory in this case | type H3_ID_ERROR. Generating an error is not mandatory in this case | |||
| because HTTP/3 implementations might have practical barriers to | because HTTP/3 implementations might have practical barriers to | |||
| determining the active stream concurrency limit that is applied by | determining the active stream concurrency limit that is applied by | |||
| the QUIC layer. | the QUIC layer. | |||
| Prioritization of HTTP/3 datagrams is not defined in this document. | Prioritization of HTTP/3 datagrams is not defined in this document. | |||
| Future extensions MAY define how to prioritize datagrams, and MAY | Future extensions MAY define how to prioritize datagrams, and MAY | |||
| define signaling to allow communicating prioritization preferences. | define signaling to allow communicating prioritization preferences. | |||
| 2.1.1. The H3_DATAGRAM HTTP/3 SETTINGS Parameter | 2.1.1. The SETTINGS_H3_DATAGRAM HTTP/3 Setting | |||
| Implementations of HTTP/3 that support HTTP Datagrams can indicate | Endpoints can indicate to their peer that they are willing to receive | |||
| that to their peer by sending the H3_DATAGRAM SETTINGS parameter with | HTTP/3 Datagrams by sending the SETTINGS_H3_DATAGRAM (0x33) setting | |||
| a value of 1. | with a value of 1. | |||
| The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or | The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. | |||
| 1. A value of 0 indicates that HTTP Datagrams are not supported. If | A value of 0 indicates that the implementation is not willing to | |||
| the H3_DATAGRAM SETTINGS parameter is received with a value that is | receive HTTP Datagrams. If the SETTINGS_H3_DATAGRAM setting is | |||
| neither 0 or 1, the receiver MUST terminate the connection with error | received with a value that is neither 0 or 1, the receiver MUST | |||
| H3_SETTINGS_ERROR. | terminate the connection with error H3_SETTINGS_ERROR. | |||
| QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS | QUIC DATAGRAM frames MUST NOT be sent until the SETTINGS_H3_DATAGRAM | |||
| parameter has been both sent and received with a value of 1. | setting has been both sent and received with a value of 1. | |||
| When clients use 0-RTT, they MAY store the value of the server's | When clients use 0-RTT, they MAY store the value of the server's | |||
| H3_DATAGRAM SETTINGS parameter. Doing so allows the client to send | SETTINGS_H3_DATAGRAM setting. Doing so allows the client to send | |||
| QUIC DATAGRAM frames in 0-RTT packets. When servers decide to accept | QUIC DATAGRAM frames in 0-RTT packets. When servers decide to accept | |||
| 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater | 0-RTT data, they MUST send a SETTINGS_H3_DATAGRAM setting greater | |||
| than or equal to the value they sent to the client in the connection | than or equal to the value they sent to the client in the connection | |||
| where they sent them the NewSessionTicket message. If a client | where they sent them the NewSessionTicket message. If a client | |||
| stores the value of the H3_DATAGRAM SETTINGS parameter with their | stores the value of the SETTINGS_H3_DATAGRAM setting with their 0-RTT | |||
| 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM | state, they MUST validate that the new value of the | |||
| SETTINGS parameter sent by the server in the handshake is greater | SETTINGS_H3_DATAGRAM setting sent by the server in the handshake is | |||
| than or equal to the stored value; if not, the client MUST terminate | greater than or equal to the stored value; if not, the client MUST | |||
| the connection with error H3_SETTINGS_ERROR. In all cases, the | terminate the connection with error H3_SETTINGS_ERROR. In all cases, | |||
| maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. | the maximum permitted value of the SETTINGS_H3_DATAGRAM setting | |||
| parameter is 1. | ||||
| It is RECOMMENDED that implementations that support receiving HTTP | It is RECOMMENDED that implementations that support receiving HTTP/3 | |||
| Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter | Datagrams always send the SETTINGS_H3_DATAGRAM setting with a value | |||
| with a value of 1, even if the application does not intend to use | of 1, even if the application does not intend to use HTTP/3 | |||
| HTTP Datagrams. This helps to avoid "sticking out"; see Section 4. | Datagrams. This helps to avoid "sticking out"; see Section 4. | |||
| 2.1.1.1. Note About Draft Versions | 2.1.1.1. Note About Draft Versions | |||
| [[RFC editor: please remove this section before publication.]] | [[RFC editor: please remove this section before publication.]] | |||
| Some revisions of this draft specification use a different value (the | Some revisions of this draft specification use a different value (the | |||
| Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the | Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the | |||
| H3_DATAGRAM Settings Parameter. This allows new draft revisions to | SETTINGS_H3_DATAGRAM setting. This allows new draft revisions to | |||
| make incompatible changes. Multiple draft versions MAY be supported | make incompatible changes. Multiple draft versions MAY be supported | |||
| by sending multiple values for H3_DATAGRAM. Once SETTINGS have been | by sending multiple values for SETTINGS_H3_DATAGRAM. Once SETTINGS | |||
| sent and received, an implementation that supports multiple drafts | have been sent and received, an implementation that supports multiple | |||
| MUST compute the intersection of the values it has sent and received, | drafts MUST compute the intersection of the values it has sent and | |||
| and then it MUST select and use the most recent draft version from | received, and then it MUST select and use the most recent draft | |||
| the intersection set. This ensures that both peers negotiate the | version from the intersection set. This ensures that both peers | |||
| same draft version. | negotiate the same draft version. | |||
| 2.2. HTTP Datagrams using Capsules | 2.2. HTTP Datagrams using Capsules | |||
| When HTTP/3 Datagrams are unavailable or undesirable, HTTP Datagrams | When HTTP/3 Datagrams are unavailable or undesirable, HTTP Datagrams | |||
| can be sent using the Capsule Protocol, see Section 3.5. | can be sent using the Capsule Protocol, see Section 3.5. | |||
| 3. Capsules | 3. Capsules | |||
| One mechanism to extend HTTP is to introduce new HTTP Upgrade Tokens | One mechanism to extend HTTP is to introduce new HTTP Upgrade Tokens | |||
| (see Section 16.7 of [HTTP]). In HTTP/1.x, these tokens are used via | (see Section 16.7 of [HTTP]). In HTTP/1.x, these tokens are used via | |||
| skipping to change at page 6, line 48 ¶ | skipping to change at page 7, line 20 ¶ | |||
| HTTP/3, these tokens are used via the Extended CONNECT mechanism (see | HTTP/3, these tokens are used via the Extended CONNECT mechanism (see | |||
| [EXT-CONNECT2] and [EXT-CONNECT3]). | [EXT-CONNECT2] and [EXT-CONNECT3]). | |||
| This specification introduces the Capsule Protocol. The Capsule | This specification introduces the Capsule Protocol. The Capsule | |||
| Protocol is a sequence of type-length-value tuples that definitions | Protocol is a sequence of type-length-value tuples that definitions | |||
| of new HTTP Upgrade Tokens can choose to use. It allows endpoints to | of new HTTP Upgrade Tokens can choose to use. It allows endpoints to | |||
| reliably communicate request-related information end-to-end on HTTP | reliably communicate request-related information end-to-end on HTTP | |||
| request streams, even in the presence of HTTP intermediaries. The | request streams, even in the presence of HTTP intermediaries. The | |||
| Capsule Protocol can be used to exchange HTTP Datagrams, which is | Capsule Protocol can be used to exchange HTTP Datagrams, which is | |||
| necessary when HTTP is running over a transport that does not support | necessary when HTTP is running over a transport that does not support | |||
| the QUIC DATAGRAM frame. | the QUIC DATAGRAM frame. The Capsule Protocol can also be used to | |||
| communicate reliable and bidirectional control messages associated | ||||
| with a datagram-based protocol even when HTTP/3 Datagrams are in use. | ||||
| 3.1. HTTP Data Streams | 3.1. HTTP Data Streams | |||
| This specification defines the "data stream" of an HTTP request as | This specification defines the "data stream" of an HTTP request as | |||
| the bidirectional stream of bytes that follows the header section of | the bidirectional stream of bytes that follows the header section of | |||
| the request message and the final, successful (i.e., 2xx) response | the request message and the final, successful (i.e., 2xx) response | |||
| message. | message. | |||
| In HTTP/1.x, the data stream consists of all bytes on the connection | In HTTP/1.x, the data stream consists of all bytes on the connection | |||
| that follow the blank line that concludes either the request header | that follow the blank line that concludes either the request header | |||
| skipping to change at page 8, line 28 ¶ | skipping to change at page 9, line 5 ¶ | |||
| forward capsules without modification, unless the definition of the | forward capsules without modification, unless the definition of the | |||
| Capsule Type in use specifies additional intermediary processing. | Capsule Type in use specifies additional intermediary processing. | |||
| One such Capsule Type is the DATAGRAM capsule; see Section 3.5. In | One such Capsule Type is the DATAGRAM capsule; see Section 3.5. In | |||
| particular, intermediaries SHOULD forward Capsules with an unknown | particular, intermediaries SHOULD forward Capsules with an unknown | |||
| Capsule Type without modification. | Capsule Type without modification. | |||
| Endpoints which receive a Capsule with an unknown Capsule Type MUST | Endpoints which receive a Capsule with an unknown Capsule Type MUST | |||
| silently drop that Capsule and skip over it to parse the next | silently drop that Capsule and skip over it to parse the next | |||
| Capsule. | Capsule. | |||
| By virtue of the definition of the data stream, the Capsule Protocol | By virtue of the definition of the data stream: | |||
| is not in use on responses unless the response includes a 2xx | ||||
| (Successful) status code. | * The Capsule Protocol is not in use unless the response includes a | |||
| 2xx (Successful) status code. | ||||
| * When the Capsule Protocol is in use, the associated HTTP request | ||||
| and response do not carry HTTP content. A future extension MAY | ||||
| define a new capsule type to carry HTTP content. | ||||
| The Capsule Protocol MUST NOT be used with messages that contain | The Capsule Protocol MUST NOT be used with messages that contain | |||
| Content-Length, Content-Type, or Transfer-Encoding header fields. | Content-Length, Content-Type, or Transfer-Encoding header fields. | |||
| Additionally, HTTP status codes 204 (No Content), 205 (Reset | Additionally, HTTP status codes 204 (No Content), 205 (Reset | |||
| Content), and 206 (Partial Content) MUST NOT be sent on responses | Content), and 206 (Partial Content) MUST NOT be sent on responses | |||
| that use the Capsule Protocol. A receiver that observes a violation | that use the Capsule Protocol. A receiver that observes a violation | |||
| of these requirements MUST treat the HTTP message as malformed. | of these requirements MUST treat the HTTP message as malformed. | |||
| 3.3. Error Handling | 3.3. Error Handling | |||
| When an error occurs in processing the Capsule Protocol, the receiver | When an error occurs in processing the Capsule Protocol, the receiver | |||
| MUST treat the message as malformed or incomplete, according to the | MUST treat the message as malformed or incomplete, according to the | |||
| underlying transport protocol. For HTTP/3, the handling of malformed | underlying transport protocol. For HTTP/3, the handling of malformed | |||
| messages is described in Section 4.1.3 of [H3]. For HTTP/2, the | messages is described in Section 4.1.3 of [HTTP/3]. For HTTP/2, the | |||
| handling of malformed messages is described in Section 8.1.1 of [H2]. | handling of malformed messages is described in Section 8.1.1 of | |||
| For HTTP/1.1, the handling of incomplete messages is described in | [HTTP/2]. For HTTP/1.1, the handling of incomplete messages is | |||
| Section 8 of [H1]. | described in Section 8 of [HTTP/1.1]. | |||
| Each capsule's payload MUST contain exactly the fields identified in | Each capsule's payload MUST contain exactly the fields identified in | |||
| its description. A capsule payload that contains additional bytes | its description. A capsule payload that contains additional bytes | |||
| after the identified fields or a capsule payload that terminates | after the identified fields or a capsule payload that terminates | |||
| before the end of the identified fields MUST be treated as a | before the end of the identified fields MUST be treated as a | |||
| malformed or incomplete message. In particular, redundant length | malformed or incomplete message. In particular, redundant length | |||
| encodings MUST be verified to be self-consistent. | encodings MUST be verified to be self-consistent. | |||
| When a stream carrying capsules terminates cleanly, if the last | If the receive side of a stream carrying capsules is terminated | |||
| capsule on the stream was truncated, this MUST be treated as a | cleanly (for example, in HTTP/3 this is defined as receiving a QUIC | |||
| malformed or incomplete message. | STREAM frame with the FIN bit set) and the last capsule on the stream | |||
| was truncated, this MUST be treated as a malformed or incomplete | ||||
| message. | ||||
| 3.4. The Capsule-Protocol Header Field | 3.4. The Capsule-Protocol Header Field | |||
| The "Capsule-Protocol" header field is an Item Structured Field, see | The "Capsule-Protocol" header field is an Item Structured Field, see | |||
| Section 3.3 of [STRUCT-FIELD]; its value MUST be a Boolean; any other | Section 3.3 of [STRUCT-FIELD]; its value MUST be a Boolean; any other | |||
| value type MUST be handled as if the field were not present by | value type MUST be handled as if the field were not present by | |||
| recipients (for example, if this field is included multiple times, | recipients (for example, if this field is included multiple times, | |||
| its type will become a List and the field will therefore be ignored). | its type will become a List and the field will therefore be ignored). | |||
| This document does not define any parameters for the Capsule-Protocol | This document does not define any parameters for the Capsule-Protocol | |||
| header field value, but future documents might define parameters. | header field value, but future documents might define parameters. | |||
| skipping to change at page 9, line 46 ¶ | skipping to change at page 10, line 26 ¶ | |||
| The Capsule-Protocol header field MUST NOT be used on HTTP responses | The Capsule-Protocol header field MUST NOT be used on HTTP responses | |||
| with a status code outside the 2xx range. | with a status code outside the 2xx range. | |||
| When using the Capsule Protocol, HTTP endpoints SHOULD send the | When using the Capsule Protocol, HTTP endpoints SHOULD send the | |||
| Capsule-Protocol header field to simplify intermediary processing. | Capsule-Protocol header field to simplify intermediary processing. | |||
| Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol | Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol | |||
| MAY alter this recommendation. | MAY alter this recommendation. | |||
| 3.5. The DATAGRAM Capsule | 3.5. The DATAGRAM Capsule | |||
| This document defines the DATAGRAM capsule type (see Section 5.4 for | This document defines the DATAGRAM (0x00) capsule type. This capsule | |||
| the value of the capsule type). This capsule allows HTTP Datagrams | allows HTTP Datagrams to be sent on a stream using the Capsule | |||
| to be sent on a stream using the Capsule Protocol. This is | Protocol. This is particularly useful when HTTP is running over a | |||
| particularly useful when HTTP is running over a transport that does | transport that does not support the QUIC DATAGRAM frame. | |||
| not support the QUIC DATAGRAM frame. | ||||
| Datagram Capsule { | Datagram Capsule { | |||
| Type (i) = DATAGRAM, | Type (i) = 0x00, | |||
| Length (i), | Length (i), | |||
| HTTP Datagram Payload (..), | HTTP Datagram Payload (..), | |||
| } | } | |||
| Figure 4: DATAGRAM Capsule Format | Figure 4: DATAGRAM Capsule Format | |||
| HTTP Datagram Payload: The payload of the datagram, whose semantics | HTTP Datagram Payload: The payload of the datagram, whose semantics | |||
| are defined by the extension that is using HTTP Datagrams. Note | are defined by the extension that is using HTTP Datagrams. Note | |||
| that this field can be empty. | that this field can be empty. | |||
| HTTP Datagrams sent using the DATAGRAM capsule have the same | HTTP Datagrams sent using the DATAGRAM capsule have the same | |||
| semantics as those sent in QUIC DATAGRAM frames. In particular, the | semantics as those sent in QUIC DATAGRAM frames. In particular, the | |||
| restrictions on when it is allowed to send an HTTP Datagram and how | restrictions on when it is allowed to send an HTTP Datagram and how | |||
| to process them from Section 2.1 also apply to HTTP Datagrams sent | to process them from Section 2.1 also apply to HTTP Datagrams sent | |||
| and received using the DATAGRAM capsule. | and received using the DATAGRAM capsule. | |||
| An intermediary can reencode HTTP Datagrams as it forwards them. In | An intermediary can reencode HTTP Datagrams as it forwards them. In | |||
| other words, an intermediary MAY send a DATAGRAM capsule to forward | other words, an intermediary MAY send a DATAGRAM capsule to forward | |||
| an HTTP Datagram which was received in a QUIC DATAGRAM frame, and | an HTTP Datagram that was received in a QUIC DATAGRAM frame, and vice | |||
| vice versa. | versa. Intermediaries MUST NOT perform this reencoding unless they | |||
| have identified the use of the Capsule Protocol on the corresponding | ||||
| request stream; see Section 3.2. | ||||
| Note that while DATAGRAM capsules that are sent on a stream are | Note that while DATAGRAM capsules that are sent on a stream are | |||
| reliably delivered in order, intermediaries can reencode DATAGRAM | reliably delivered in order, intermediaries can reencode DATAGRAM | |||
| capsules into QUIC DATAGRAM frames when forwarding messages, which | capsules into QUIC DATAGRAM frames when forwarding messages, which | |||
| could result in loss or reordering. | could result in loss or reordering. | |||
| If an intermediary receives an HTTP Datagram in a QUIC DATAGRAM frame | If an intermediary receives an HTTP Datagram in a QUIC DATAGRAM frame | |||
| and is forwarding it on a connection that supports QUIC DATAGRAM | and is forwarding it on a connection that supports QUIC DATAGRAM | |||
| frames, the intermediary SHOULD NOT convert that HTTP Datagram to a | frames, the intermediary SHOULD NOT convert that HTTP Datagram to a | |||
| DATAGRAM capsule. If the HTTP Datagram is too large to fit in a | DATAGRAM capsule. If the HTTP Datagram is too large to fit in a | |||
| skipping to change at page 11, line 8 ¶ | skipping to change at page 11, line 41 ¶ | |||
| While DATAGRAM capsules can theoretically carry a payload of length | While DATAGRAM capsules can theoretically carry a payload of length | |||
| 2^62-1, most HTTP extensions that use HTTP Datagrams will have their | 2^62-1, most HTTP extensions that use HTTP Datagrams will have their | |||
| own limits on what datagram payload sizes are practical. | own limits on what datagram payload sizes are practical. | |||
| Implementations SHOULD take those limits into account when parsing | Implementations SHOULD take those limits into account when parsing | |||
| DATAGRAM capsules: if an incoming DATAGRAM capsule has a length that | DATAGRAM capsules: if an incoming DATAGRAM capsule has a length that | |||
| is known to be so large as to not be usable, the implementation | is known to be so large as to not be usable, the implementation | |||
| SHOULD discard the capsule without buffering its contents into | SHOULD discard the capsule without buffering its contents into | |||
| memory. | memory. | |||
| Note that use of the Capsule Protocol is not required to use HTTP | Note that it is possible for an HTTP extension to use HTTP Datagrams | |||
| Datagrams. If an HTTP extension that uses HTTP Datagrams is only | without using the Capsule Protocol. For example, if an HTTP | |||
| defined over transports that support QUIC DATAGRAM frames, it might | extension that uses HTTP Datagrams is only defined over transports | |||
| not need a stream encoding. Additionally, HTTP extensions can use | that support QUIC DATAGRAM frames, it might not need a stream | |||
| HTTP Datagrams with their own data stream protocol. However, new | encoding. Additionally, HTTP extensions can use HTTP Datagrams with | |||
| HTTP extensions that wish to use HTTP Datagrams SHOULD use the | their own data stream protocol. However, new HTTP extensions that | |||
| Capsule Protocol unless they have a good reason not to. | wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing | |||
| to do so will make it harder for the HTTP extension to support | ||||
| versions of HTTP other than HTTP/3 and will prevent interoperability | ||||
| with intermediaries that only support the Capsule Protocol. | ||||
| 4. Security Considerations | 4. Security Considerations | |||
| Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires | Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires | |||
| sending an HTTP/3 Settings parameter, it "sticks out". In other | sending the HTTP/3 SETTINGS_H3_DATAGRAM setting, it "sticks out". In | |||
| words, probing clients can learn whether a server supports HTTP | other words, probing clients can learn whether a server supports HTTP | |||
| Datagrams over QUIC DATAGRAM frames. As some servers might wish to | Datagrams over QUIC DATAGRAM frames. As some servers might wish to | |||
| obfuscate the fact that they offer application services that use HTTP | obfuscate the fact that they offer application services that use HTTP | |||
| datagrams, it's best for all implementations that support this | datagrams, it's best for all implementations that support this | |||
| feature to always send this Settings parameter, see Section 2.1.1. | feature to always send this setting, see Section 2.1.1. | |||
| Since use of the Capsule Protocol is restricted to new HTTP Upgrade | Since use of the Capsule Protocol is restricted to new HTTP Upgrade | |||
| Tokens, it is not accessible from Web Platform APIs (such as those | Tokens, it is not accessible from Web Platform APIs (such as those | |||
| commonly accessed via JavaScript in web browsers). | commonly accessed via JavaScript in web browsers). | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| 5.1. HTTP/3 SETTINGS Parameter | 5.1. HTTP/3 Setting | |||
| This document will request IANA to register the following entry in | This document will request IANA to register the following entry in | |||
| the "HTTP/3 Settings" registry: | the "HTTP/3 Settings" registry: | |||
| Value: 0xffd277 (note that this will switch to a lower value before | Value: 0x33 | |||
| publication) | Setting Name: SETTINGS_H3_DATAGRAM | |||
| Setting Name: H3_DATAGRAM | ||||
| Default: 0 | Default: 0 | |||
| Status: provisional (permanent if this document is approved) | Status: provisional (permanent if this document is approved) | |||
| Specification: This Document | Specification: This Document | |||
| Change Controller: IETF | Change Controller: IETF | |||
| Contact: HTTP_WG; HTTP working group; ietf-http-wg@w3.org | Contact: HTTP_WG; HTTP working group; ietf-http-wg@w3.org | |||
| 5.2. HTTP/3 Error Code | 5.2. HTTP/3 Error Code | |||
| This document will request IANA to register the following entry in | This document will request IANA to register the following entry in | |||
| the "HTTP/3 Error Codes" registry: | the "HTTP/3 Error Codes" registry: | |||
| Value: 0x4A1268 (note that this will switch to a lower value before | Value: 0x33 | |||
| publication) | ||||
| Name: H3_DATAGRAM_ERROR | Name: H3_DATAGRAM_ERROR | |||
| Description: Datagram or capsule protocol parse error | Description: Datagram or capsule protocol parse error | |||
| Status: provisional (permanent if this document is approved) | Status: provisional (permanent if this document is approved) | |||
| Specification: This Document | Specification: This Document | |||
| Change Controller: IETF | Change Controller: IETF | |||
| Contact: HTTP_WG; HTTP working group; ietf-http-wg@w3.org | Contact: HTTP_WG; HTTP working group; ietf-http-wg@w3.org | |||
| 5.3. HTTP Header Field Name | 5.3. HTTP Header Field Name | |||
| This document will request IANA to register the following entry in | This document will request IANA to register the following entry in | |||
| the "HTTP Field Name" registry: | the "HTTP Field Name" registry: | |||
| Field Name: Capsule-Protocol | Field Name: Capsule-Protocol | |||
| Template: None | Template: None | |||
| Status: provisional (permanent if this document is approved) | Status: provisional (permanent if this document is approved) | |||
| Reference: This document | Reference: This document | |||
| Comments: None | Comments: None | |||
| 5.4. Capsule Types | 5.4. Capsule Types | |||
| This document establishes a registry for HTTP capsule type codes. | This document establishes a registry for HTTP capsule type codes. | |||
| The "HTTP Capsule Types" registry governs a 62-bit space. | The "HTTP Capsule Types" registry governs a 62-bit space, and | |||
| Registrations in this registry MUST include the following fields: | operates under the QUIC registration policy documented in | |||
| Section 22.1 of [QUIC]. This new registry includes the common set of | ||||
| Type: A name or label for the capsule type. | fields listed in Section 22.1.1 of [QUIC]. In addition to those | |||
| common fields, all registrations in this registry MUST include a | ||||
| Value: The value of the Capsule Type field (see Section 3.2) is a | "Capsule Type" field which contains a short name or label for the | |||
| 62-bit integer. | capsule type. | |||
| Reference: An optional reference to a specification for the type. | Permanent registrations in this registry are assigned using the | |||
| This field MAY be empty. | Specification Required policy (Section 4.6 of [IANA-POLICY]), except | |||
| for values between 0x00 and 0x3f (in hexadecimal; inclusive), which | ||||
| are assigned using Standards Action or IESG Approval as defined in | ||||
| Sections 4.9 and 4.10 of [IANA-POLICY]. | ||||
| Registrations follow the "First Come First Served" policy (see | Capsule types with a value of the form 0x29 * N + 0x17 for integer | |||
| Section 4.4 of [IANA-POLICY]) where two registrations MUST NOT have | values of N are reserved to exercise the requirement that unknown | |||
| the same Type. | capsule types be ignored. These capsules have no semantics and can | |||
| carry arbitrary values. These values MUST NOT be assigned by IANA | ||||
| and MUST NOT appear in the listing of assigned values. | ||||
| This registry initially contains the following entry: | This registry initially contains the following entry: | |||
| Value: 0x00 | ||||
| Capsule Type: DATAGRAM | Capsule Type: DATAGRAM | |||
| Status: permanent | ||||
| Value: 0xff37a5 (note that this will switch to a lower value before | Specification: This document | |||
| publication) | Change Controller: IETF | |||
| Contact: MASQUE Working Group masque@ietf.org | ||||
| Reference: This document | (mailto:masque@ietf.org) | |||
| Notes: None | ||||
| Capsule types with a value of the form 41 * N + 23 for integer values | ||||
| of N are reserved to exercise the requirement that unknown capsule | ||||
| types be ignored. These capsules have no semantics and can carry | ||||
| arbitrary values. These values MUST NOT be assigned by IANA and MUST | ||||
| NOT appear in the listing of assigned values. | ||||
| 6. References | 6. References | |||
| 6.1. Normative References | 6.1. Normative References | |||
| [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable | [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable | |||
| Datagram Extension to QUIC", Work in Progress, Internet- | Datagram Extension to QUIC", RFC 9221, | |||
| Draft, draft-ietf-quic-datagram-10, 4 February 2022, | DOI 10.17487/RFC9221, March 2022, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://www.rfc-editor.org/rfc/rfc9221>. | |||
| datagram-10>. | ||||
| [H1] Fielding, R. T., Nottingham, M., and J. Reschke, | [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP | |||
| Semantics", Work in Progress, Internet-Draft, draft-ietf- | ||||
| httpbis-semantics-19, 12 September 2021, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- | ||||
| semantics-19>. | ||||
| [HTTP/1.1] Fielding, R. T., Nottingham, M., and J. Reschke, | ||||
| "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- | "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- | |||
| httpbis-messaging-19, 12 September 2021, | httpbis-messaging-19, 12 September 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- | <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- | |||
| messaging-19>. | messaging-19>. | |||
| [H2] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, | [HTTP/2] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, | |||
| Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January | Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January | |||
| 2022, <https://datatracker.ietf.org/doc/html/draft-ietf- | 2022, <https://datatracker.ietf.org/doc/html/draft-ietf- | |||
| httpbis-http2bis-07>. | httpbis-http2bis-07>. | |||
| [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 | [HTTP/3] Bishop, M., "Hypertext Transfer Protocol Version 3 | |||
| (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- | (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- | |||
| quic-http-34, 2 February 2021, | quic-http-34, 2 February 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | <https://datatracker.ietf.org/doc/html/draft-ietf-quic- | |||
| http-34>. | http-34>. | |||
| [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP | ||||
| Semantics", Work in Progress, Internet-Draft, draft-ietf- | ||||
| httpbis-semantics-19, 12 September 2021, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- | ||||
| semantics-19>. | ||||
| [IANA-POLICY] | [IANA-POLICY] | |||
| Cotton, M., Leiba, B., and T. Narten, "Guidelines for | Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
| Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
| RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
| <https://www.rfc-editor.org/rfc/rfc8126>. | <https://www.rfc-editor.org/rfc/rfc8126>. | |||
| [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
| Multiplexed and Secure Transport", RFC 9000, | Multiplexed and Secure Transport", RFC 9000, | |||
| DOI 10.17487/RFC9000, May 2021, | DOI 10.17487/RFC9000, May 2021, | |||
| <https://www.rfc-editor.org/rfc/rfc9000>. | <https://www.rfc-editor.org/rfc/rfc9000>. | |||
| skipping to change at page 15, line 28 ¶ | skipping to change at page 15, line 40 ¶ | |||
| [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", | [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", | |||
| RFC 6455, DOI 10.17487/RFC6455, December 2011, | RFC 6455, DOI 10.17487/RFC6455, December 2011, | |||
| <https://www.rfc-editor.org/rfc/rfc6455>. | <https://www.rfc-editor.org/rfc/rfc6455>. | |||
| Acknowledgments | Acknowledgments | |||
| Portions of this document were previously part of the QUIC DATAGRAM | Portions of this document were previously part of the QUIC DATAGRAM | |||
| frame definition itself, the authors would like to acknowledge the | frame definition itself, the authors would like to acknowledge the | |||
| authors of that document and the members of the IETF MASQUE working | authors of that document and the members of the IETF MASQUE working | |||
| group for their suggestions. Additionally, the authors would like to | group for their suggestions. Additionally, the authors would like to | |||
| thank Martin Thomson for suggesting the use of an HTTP/3 SETTINGS | thank Martin Thomson for suggesting the use of an HTTP/3 setting. | |||
| parameter. Furthermore, the authors would like to thank Ben Schwartz | Furthermore, the authors would like to thank Ben Schwartz for writing | |||
| for writing the first proposal that used two layers of indirection. | the first proposal that used two layers of indirection. The final | |||
| The final design in this document came out of the HTTP Datagrams | design in this document came out of the HTTP Datagrams Design Team, | |||
| Design Team, whose members were Alan Frindell, Alex Chernyakhovsky, | whose members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, | |||
| Ben Schwartz, Eric Rescorla, Marcus Ihlar, Martin Thomson, Mike | Eric Rescorla, Marcus Ihlar, Martin Thomson, Mike Bishop, Tommy | |||
| Bishop, Tommy Pauly, Victor Vasiliev, and the authors of this | Pauly, Victor Vasiliev, and the authors of this document. The | |||
| document. The authors thank Mark Nottingham and Philipp Tiesel for | authors thank Mark Nottingham and Philipp Tiesel for their helpful | |||
| their helpful comments. | comments. | |||
| Authors' Addresses | Authors' Addresses | |||
| David Schinazi | David Schinazi | |||
| Google LLC | Google LLC | |||
| 1600 Amphitheatre Parkway | 1600 Amphitheatre Parkway | |||
| Mountain View, California 94043, | Mountain View, CA 94043 | |||
| United States of America | United States of America | |||
| Email: dschinazi.ietf@gmail.com | Email: dschinazi.ietf@gmail.com | |||
| Lucas Pardue | Lucas Pardue | |||
| Cloudflare | Cloudflare | |||
| Email: lucaspardue.24.7@gmail.com | Email: lucaspardue.24.7@gmail.com | |||
| End of changes. 70 change blocks. | ||||
| 180 lines changed or deleted | 184 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/ | ||||