RFC 9297

HTTP Datagrams and the Capsule Protocol 🎀

Okay bestie, this is RFC 9297 💖 It's a Standards Track document from the IETF, dated August 2022 and published under ISSN 2070-1721 ✨. The authors are D. Schinazi from Google LLC and L. Pardue from Cloudflare 🧚. The title block doesn't list any RFCs it obsoletes or updates, so this one stands on its own 🦋.

Abstract ✨

So this doc describes HTTP Datagrams, a way to send multiplexed, maybe-unreliable datagrams inside an HTTP connection 🫶

In HTTP/3, HTTP Datagrams can go unreliable by using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame isn't available or isn't what you want, you can send HTTP Datagrams with the Capsule Protocol instead. That's a more general way to move data around in HTTP connections 💅

HTTP Datagrams and the Capsule Protocol are meant for HTTP extensions to use, not for applications 👑

Status of This Memo 📜

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 🌸

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9297 🧚

Copyright Notice 🌈

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 🦋

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Revised BSD License ⭐

Table of Contents 📑

   1.  Introduction
     1.1.  Conventions and Definitions
   2.  HTTP Datagrams
     2.1.  HTTP/3 Datagrams
       2.1.1.  The SETTINGS_H3_DATAGRAM HTTP/3 Setting
     2.2.  HTTP Datagrams Using Capsules
   3.  Capsules
     3.1.  HTTP Data Streams
     3.2.  The Capsule Protocol
     3.3.  Error Handling
     3.4.  The Capsule-Protocol Header Field
     3.5.  The DATAGRAM Capsule
   4.  Security Considerations
   5.  IANA Considerations
     5.1.  HTTP/3 Setting
     5.2.  HTTP/3 Error Code
     5.3.  HTTP Header Field Name
     5.4.  Capsule Types
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgments
   Authors' Addresses

---

1. Introduction ✨

okay so HTTP extensions (as defined in Section 16 of [HTTP]) sometimes need to reach down into the transport protocol for stuff like unreliable delivery (as offered by [QUIC-DGRAM]) to unlock features 💖 For example, this could give us an unreliable version of the CONNECT method, and it could add unreliable delivery to WebSockets [WEBSOCKET] 🦋

In Section 2, this doc describes HTTP Datagrams, a way to send bidirectional, potentially unreliable datagrams inside an HTTP connection, multiplexed whenever that's possible 🧚 HTTP Datagrams are tied to HTTP requests, but they're not part of message content. They're meant for HTTP extensions (like the CONNECT method), and they work with every version of HTTP 🫶

When HTTP runs over a transport that supports unreliable delivery (like when the QUIC DATAGRAM extension [QUIC-DGRAM] is available to HTTP/3 [HTTP/3]), HTTP Datagrams can use that capability 🌸

In Section 3, this doc describes the HTTP Capsule Protocol, which lets you send HTTP Datagrams with reliable delivery 💅 This covers HTTP/3 cases where the QUIC DATAGRAM frame is unavailable or undesirable, and cases where the transport only gives reliable delivery, like HTTP/1.1 [HTTP/1.1] or HTTP/2 [HTTP/2] over TCP [TCP] 👑

1.1. Conventions and Definitions 📚

Here's the key word situation 🤓 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document uses terminology from [QUIC] ✨

When the doc defines protocol types, the definition format uses the notation from Section 1.3 of [QUIC]. When fields within types are integers, they're encoded with the variable-length integer encoding from Section 16 of [QUIC]. Integer values don't have to be encoded on the minimum number of bytes necessary 🙈

In this document, "intermediary" refers to an HTTP intermediary as defined in Section 3.7 of [HTTP] 🧚

2. HTTP Datagrams 🦋

HTTP Datagrams are a convention for conveying bidirectional and potentially unreliable datagrams inside an HTTP connection, with multiplexing when possible 💖 Every HTTP Datagram is associated with an HTTP request 🫶

When HTTP Datagrams are conveyed on an HTTP/3 connection, the QUIC DATAGRAM frame can give you demultiplexing and unreliable delivery. See Section 2.1 for that. Negotiating QUIC DATAGRAM frames for HTTP Datagrams happens through an exchange of HTTP/3 settings. See Section 2.1.1 🌸

When you're running over HTTP/2, demultiplexing comes from the HTTP/2 framing layer, but unreliable delivery isn't available. HTTP Datagrams get negotiated and conveyed with the Capsule Protocol. See Section 3.5 💅

When you're running over HTTP/1.x, requests are strictly serialized on the connection, so demultiplexing isn't available. Unreliable delivery isn't available either. HTTP Datagrams get negotiated and conveyed with the Capsule Protocol. See Section 3.5 👑

HTTP Datagrams MUST only be sent with an association to an HTTP request that explicitly supports them 🙅 For example, the existing HTTP methods GET and POST don't define semantics for associated HTTP Datagrams. So HTTP Datagrams tied to GET or POST request streams can't be sent 💀

If an HTTP Datagram arrives and it's associated with a request that has no known semantics for HTTP Datagrams, the receiver MUST terminate the request. If HTTP/3 is in use, the request stream MUST be aborted with H3_DATAGRAM_ERROR (0x33). HTTP extensions MAY override these requirements by defining a negotiation mechanism and semantics for HTTP Datagrams ✨

2.1. HTTP/3 Datagrams 🎀

When you use HTTP/3, the Datagram Data field of QUIC DATAGRAM frames uses this format:

HTTP/3 Datagram {
  Quarter Stream ID (i),
  HTTP Datagram Payload (..),
}

Figure 1: HTTP/3 Datagram Format

• Quarter Stream ID: a variable-length integer holding the client-initiated bidirectional stream value this datagram belongs to, divided by four. We divide by four because HTTP requests go on client-initiated bidirectional streams, and those stream IDs are always divisible by four 🧚 The largest legal QUIC stream ID is 2^62-1, so the largest legal value of the Quarter Stream ID field is 2^60-1. 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 (0x33) 💀
• HTTP Datagram Payload: the payload of the datagram. Its semantics are defined by the extension using HTTP Datagrams. This field can be empty 🫶

Receipt of a QUIC DATAGRAM frame whose payload is too short to parse the Quarter Stream ID field MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR (0x33) 🙈

HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's send side is open. If a datagram arrives after the corresponding stream's receive side is closed, the received datagrams MUST be silently dropped 🙅

If an HTTP/3 Datagram arrives and its Quarter Stream ID field maps to a stream that hasn't been created yet, the receiver SHALL either drop that datagram silently or buffer it temporarily (on the order of a round trip) while it waits for the corresponding stream to be created 🦋

If an HTTP/3 Datagram arrives and its Quarter Stream ID field maps to a stream that can't be created because of client-initiated bidirectional stream limits, it SHOULD be treated as an HTTP/3 connection error of type H3_ID_ERROR. Generating an error isn't mandatory, because the QUIC stream limit might be unknown to the HTTP/3 layer 🤓

Prioritization of HTTP/3 Datagrams isn't defined in this document. Future extensions MAY define how to prioritize datagrams, and they MAY define signaling so peers can communicate prioritization preferences 👑

2.1.1. The SETTINGS_H3_DATAGRAM HTTP/3 Setting 💜

An endpoint can tell its peer it's willing to receive HTTP/3 Datagrams by sending the SETTINGS_H3_DATAGRAM (0x33) setting with a value of 1 ✨

The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. A value of 0 means the implementation isn't willing to receive HTTP Datagrams. If the SETTINGS_H3_DATAGRAM setting arrives with a value that's neither 0 nor 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR 😭

QUIC DATAGRAM frames MUST NOT be sent until the SETTINGS_H3_DATAGRAM 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 SETTINGS_H3_DATAGRAM setting. Doing that lets the client send QUIC DATAGRAM frames in 0-RTT packets 🧚 When servers decide to accept 0-RTT data, they MUST send a SETTINGS_H3_DATAGRAM setting greater than or equal to the value they sent to the client on the connection where they sent the NewSessionTicket message. If a client stores the value of the SETTINGS_H3_DATAGRAM setting along with its 0-RTT state, the client MUST validate that the new value of the SETTINGS_H3_DATAGRAM setting the server sent in the handshake is greater than or equal to the stored value. If it isn't, the client MUST terminate the connection with error H3_SETTINGS_ERROR. In all cases, the maximum permitted value of the SETTINGS_H3_DATAGRAM setting parameter is 1 💅

It is RECOMMENDED that implementations which support receiving HTTP/3 Datagrams always send the SETTINGS_H3_DATAGRAM setting with a value of 1, even if the application doesn't plan to use HTTP/3 Datagrams. This helps avoid "sticking out"; see Section 4 🌸

2.2. HTTP Datagrams Using Capsules 🦋

When HTTP/3 Datagrams are unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol; see Section 3.5 ✨

3. Capsules 🎀

okay so the first thing you need to know is that there's a way to extend HTTP by inventing brand new HTTP upgrade tokens 💅. Section 16.7 of [HTTP] is where that's explained. In HTTP/1.x you use them through the Upgrade mechanism (Section 7.8 of [HTTP] 🧚), and in HTTP/2 and HTTP/3 you use them through Extended CONNECT, which is covered in [EXT-CONNECT2] and [EXT-CONNECT3] 🦋.

This spec introduces the Capsule Protocol and I am obsessed 😭. It's a sequence of type-length-value tuples, and any definition of a new HTTP upgrade token can choose to use it 🌈. The main thing it does is let endpoints reliably pass request-related info end-to-end on HTTP request streams, even when there are HTTP intermediaries sitting in the middle 🫶. It can also carry HTTP Datagrams, which matters when HTTP is running over a transport that doesn't support the QUIC DATAGRAM frame ✨. And it can send reliable, bidirectional control messages tied to a datagram-based protocol even when HTTP/3 Datagrams are already being used 💜.

---

3.1. HTTP Data Streams 🌸

so here's the big idea: this spec defines the "data stream" of an HTTP request as the bidirectional stream of bytes that comes after the header section of the request message and after the final response message. That final response has to be either successful (i.e., 2xx) or upgraded (i.e., 101) 💖.

In HTTP/1.x, the data stream is every byte on the connection that comes after the blank line that ends either the request header section or the final response header section 🍓. The result is that only the very last HTTP request on an HTTP/1.x connection can start the Capsule Protocol 🙈.

In HTTP/2 and HTTP/3, the data stream of a request is all the bytes sent in DATA frames with that request's stream ID ✨.

The data stream idea is especially useful for methods like CONNECT, where there's no HTTP message content after the headers at all 🧚.

You can prioritize data streams with whatever works for stream or request prioritization. For example, look at Section 11 of [PRIORITY] 💅.

Data streams are also subject to the flow control of whatever layers are underneath them. Some examples are HTTP/2 stream flow control, HTTP/2 connection flow control, and TCP flow control 🎀.

---

3.2. The Capsule Protocol 👑

new HTTP upgrade token definitions can say that their request's data stream uses the Capsule Protocol 💖. If they do, the contents of that data stream follow this format:

Capsule Protocol {
  Capsule (..) ...,
}

Figure 2: Capsule Protocol Stream Format

Capsule {
  Capsule Type (i),
  Capsule Length (i),
  Capsule Value (..),
}

Figure 3: Capsule Format

here's what each field in a Capsule is:

• Capsule Type: a variable-length integer that tells you what kind of capsule it is. An IANA registry manages the assignment of Capsule Types, so check Section 5.4 for that 📋.
• Capsule Length: the length in bytes of the Capsule Value field that comes right after it. It's encoded as a variable-length integer. Also, this one can totally be zero 🫧.
• Capsule Value: the payload of the Capsule. What it means depends on the Capsule Type 🦋.

an intermediary can spot that the Capsule Protocol is in use either by seeing the Capsule-Protocol header field (Section 3.4) or by recognizing the HTTP Upgrade token that was picked 🔍.

okay this part is so smart 🧠. New protocols or extensions might define brand new Capsule Types, so intermediaries that want to allow for future extensibility SHOULD forward Capsules without modification, unless the definition of the Capsule Type in use says they need to do extra processing. The DATAGRAM Capsule is one of those types, and you can read about it in Section 3.5 🌈. To be extra clear, intermediaries SHOULD forward Capsules with an unknown Capsule Type without modification too 💜.

Endpoints that get a Capsule with an unknown Capsule Type MUST silently drop it and skip over it so they can parse the next Capsule. no drama, just keep moving 🙅‍♀️✨

by virtue of how the data stream is defined:

• The Capsule Protocol is not in use unless the response has a 2xx (Successful) or 101 (Switching Protocols) 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 only applies to definitions of new HTTP upgrade tokens, so in HTTP/2 and HTTP/3 it can only be used with the CONNECT method 🙃. That means once both endpoints agree to use the Capsule Protocol, the frame usage requirements of the stream change as described in Section 8.5 of [HTTP/2] and Section 4.4 of [HTTP/3] 🔥.

The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields. Also, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses that use the Capsule Protocol. A receiver that sees a violation of these requirements MUST treat the HTTP message as malformed. no exceptions, bestie 💀

when a receiver is processing Capsules, it might be tempted to pile up the whole Capsule Value in the data stream before handling it. ngl that's the vibe to avoid. That approach SHOULD be avoided, because it can eat up flow control in the underlying layers, and that could cause deadlocks if the Capsule data fills the whole flow control window 😭🫠.

---

3.3. Error Handling 🙈

when a receiver runs into an error while processing the Capsule Protocol, it MUST treat that error as if it had received a malformed or incomplete HTTP message 🚨. For HTTP/3, malformed messages are handled as described in Section 4.1.2 of [HTTP/3]. For HTTP/2, they're handled as described in Section 8.1.1 of [HTTP/2]. For HTTP/1.x, incomplete messages are handled as described in Section 8 of [HTTP/1.1] 📚.

Each Capsule's payload MUST contain exactly the fields listed in its description 🎯. A Capsule payload with extra bytes after those fields, or one that ends before the end of those fields, MUST be treated as if it were a malformed or incomplete message. Redundant length encodings MUST be checked to make sure they agree with each other 🧐.

if the receive side of a stream carrying Capsules gets terminated cleanly (for example, in HTTP/3 this means receiving a QUIC STREAM frame with the FIN bit set) and the last Capsule on that stream was truncated, this MUST be treated as if it were a malformed or incomplete message 😱.

---

3.4. The Capsule-Protocol Header Field 🧚

the "Capsule-Protocol" header field is an Item Structured Field. Check Section 3.3 of [STRUCTURED-FIELDS] for the details 💜. Its value MUST be a Boolean. Any other value type MUST be handled by recipients as if the field weren't there at all. For example, if this field shows up multiple times, its type becomes a List and the field gets ignored 🙃. This document doesn't define any parameters for the Capsule-Protocol header field value, but future documents might 🔮. Receivers MUST ignore unknown parameters 🫶.

endpoints tell each other the Capsule Protocol is in use on a data stream by sending a Capsule-Protocol header field with a true value ✨. A Capsule-Protocol header field with a false value has the same meaning as when the header isn't present at all 🌸.

intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown HTTP upgrade tokens. Heads up, though: that's only possible for HTTP Upgrade or Extended CONNECT 🦋.

the Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code that is both different from 101 (Switching Protocols) and outside the 2xx (Successful) range 🚫.

when you're using the Capsule Protocol, HTTP endpoints SHOULD send the Capsule-Protocol header field to make intermediary processing simpler 🍓. Definitions of new HTTP upgrade tokens that use the Capsule Protocol MAY change this recommendation 🌈.

3.5. The DATAGRAM Capsule 💌

Okay bestie, this is the DATAGRAM (0x00) Capsule Type, and it's giving main character energy 🦋. It lets HTTP Datagrams ride along on a stream using the Capsule Protocol. It's super useful when HTTP is running over a transport that doesn't support the QUIC DATAGRAM frame 🧚.

Here's the format:

Datagram Capsule {
  Type (i) = 0x00,
  Length (i),
  HTTP Datagram Payload (..),
}

Figure 4: DATAGRAM Capsule Format

• HTTP Datagram Payload: This is the actual payload of the datagram. Its meaning is defined by whatever extension is using HTTP Datagrams 💜. Also, this field can be totally empty, and that's allowed 🫶.

HTTP Datagrams sent in a DATAGRAM Capsule have the same semantics as ones sent in QUIC DATAGRAM frames 💅. So the rules about when you're allowed to send an HTTP Datagram and how to process one (from Section 2.1) also apply to the ones going through DATAGRAM Capsules. No special treatment, no drama 🌸.

Intermediaries get a little extra freedom here ✨. An intermediary MAY send a DATAGRAM Capsule to forward an HTTP Datagram that came in a QUIC DATAGRAM frame, and vice versa. But intermediaries MUST NOT perform this re-encoding unless they've identified the use of the Capsule Protocol on the corresponding request stream. See Section 3.2 for that 🙈.

Quick heads up: DATAGRAM Capsules are sent on a stream, so they're reliably delivered and kept in order 🍓. But if an intermediary re-encodes them into QUIC DATAGRAM frames while forwarding, you can get loss or reordering. Plan accordingly, babe 😭.

Now the tricky part 👀. If an intermediary gets an HTTP Datagram in a QUIC DATAGRAM frame and is forwarding it over a connection that supports QUIC DATAGRAM frames, it SHOULD NOT convert that HTTP Datagram into a DATAGRAM Capsule. And if the HTTP Datagram is too big to fit in a DATAGRAM frame (say the Path MTU (PMTU) of that QUIC connection is too low, or the maximum UDP payload size advertised on that connection is too low), the intermediary SHOULD drop the HTTP Datagram instead of converting it. Why? Because this keeps the end-to-end unreliability property that methods like Datagram Packetization Layer PMTU Discovery (DPLPMTUD) rely on [DPLPMTUD] 🦋. If you turn QUIC DATAGRAM frames into DATAGRAM Capsules, HTTP Datagrams can become arbitrarily large with no loss at all. That can totally misrepresent the true path properties and wreck methods like DPLPMTUD 💀.

DATAGRAM Capsules can theoretically carry a payload of length 2^62-1 🙈. But most HTTP extensions that use HTTP Datagrams will have their own limits on what datagram payload sizes are practical. Implementations SHOULD take those limits into account when parsing DATAGRAM Capsules. And if an incoming DATAGRAM Capsule has a length that's known to be too large to be usable, the implementation SHOULD discard the Capsule without buffering its contents into memory. Don't hoard the bytes, bestie 🧺.

Also, QUIC DATAGRAM frames are required to fit within a QUIC packet. So implementations that re-encode DATAGRAM Capsules into QUIC DATAGRAM frames might be tempted to accumulate the entire Capsule in the stream before re-encoding it. This SHOULD be avoided, because it can cause flow control problems; see Section 3.2 ⚠️.

Last but not least 💖: it is possible for an HTTP extension to use HTTP Datagrams without the Capsule Protocol. For example, if an extension is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding at all. HTTP extensions can also use HTTP Datagrams with their own data stream protocol. Still, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol. Skipping it makes it harder for the extension to support versions of HTTP other than HTTP/3, and it blocks interoperability with intermediaries that only support the Capsule Protocol 🙅‍♀️.

---

4. Security Considerations 🔐

Okay, this part is serious but I'm still obsessed 🙈. Since sending HTTP Datagrams over QUIC DATAGRAM frames requires sending the HTTP/3 SETTINGS_H3_DATAGRAM setting, it "sticks out" 👀. In other words, probing clients can learn whether a server supports HTTP Datagrams over QUIC DATAGRAM frames. Some servers might want to hide the fact that they offer application services that use HTTP Datagrams, so it's best for all implementations that support this feature to always send this setting. See Section 2.1.1 💅.

Since use of the Capsule Protocol is restricted to new HTTP upgrade tokens, it isn't directly accessible from Web Platform APIs (like the ones commonly accessed via JavaScript in web browsers) 🫢.

Definitions of new HTTP upgrade tokens that use the Capsule Protocol need to include a security analysis that considers the impact of HTTP Datagrams and Capsules in the context of their protocol. No skipping this, period 🔥.

---

5. IANA Considerations 🧾

5.1. HTTP/3 Setting

IANA has registered the following entry in the "HTTP/3 Settings" registry maintained at <https://www.iana.org/assignments/ http3-parameters>:

Value:  0x33
Setting Name:  SETTINGS_H3_DATAGRAM
Default:  0
Status:  permanent
Reference:  RFC 9297
Change Controller:  IETF
Contact:  HTTP_WG; HTTP working group; ietf-http-wg@w3.org
Notes:  None

5.2. HTTP/3 Error Code

IANA has registered the following entry in the "HTTP/3 Error Codes" registry maintained at <https://www.iana.org/assignments/ http3-parameters>:

Value:  0x33
Name:  H3_DATAGRAM_ERROR
Description:  Datagram or Capsule Protocol parse error
Status:  permanent
Reference:  RFC 9297
Change Controller:  IETF
Contact:  HTTP_WG; HTTP working group; ietf-http-wg@w3.org
Notes:  None

5.3. HTTP Header Field Name

IANA has registered the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <https://www.iana.org/assignments/http-fields>:

Field Name:  Capsule-Protocol
Template:  None
Status:  permanent
Reference:  RFC 9297
Comments:  None

5.4. Capsule Types

This document sets up a registry for HTTP Capsule Type codes 🎀. The "HTTP Capsule Types" registry governs a 62-bit space and runs under the QUIC registration policy documented in Section 22.1 of [QUIC]. This new registry includes the common set of fields listed in Section 22.1.1 of [QUIC]. On top of those common fields, all registrations in this registry MUST include a "Capsule Type" field that holds a short name or label for the Capsule Type ✨.

Permanent registrations in this registry are assigned using the Specification Required policy (Section 4.6 of [IANA-POLICY]). The exception is 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] 📜.

Capsule Types with a value of the form 0x29 * N + 0x17 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.

The registry initially contains the following entry:

Value:  0x00
Capsule Type:  DATAGRAM
Status:  permanent
Reference:  RFC 9297
Change Controller:  IETF
Contact:  MASQUE Working Group masque@ietf.org
   (mailto:masque@ietf.org)
Notes:  None

---

6. References 📚

6.1. Normative References

[HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "HTTP Semantics", STD 97, RFC 9110,
           DOI 10.17487/RFC9110, June 2022,
           <https://www.rfc-editor.org/info/rfc9110>.

[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
           June 2022, <https://www.rfc-editor.org/info/rfc9112>.

[HTTP/2]   Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
           DOI 10.17487/RFC9113, June 2022,
           <https://www.rfc-editor.org/info/rfc9113>.

[HTTP/3]   Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
           June 2022, <https://www.rfc-editor.org/info/rfc9114>.

[IANA-POLICY]
           Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

[QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
           Multiplexed and Secure Transport", RFC 9000,
           DOI 10.17487/RFC9000, May 2021,
           <https://www.rfc-editor.org/info/rfc9000>.

[QUIC-DGRAM]
           Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
           Datagram Extension to QUIC", RFC 9221,
           DOI 10.17487/RFC9221, March 2022,
           <https://www.rfc-editor.org/info/rfc9221>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[STRUCTURED-FIELDS]
           Nottingham, M. and P-H. Kamp, "Structured Field Values for
           HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
           <https://www.rfc-editor.org/info/rfc8941>.

[TCP]      Eddy, W., Ed., "Transmission Control Protocol (TCP)",
           STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
           <https://www.rfc-editor.org/info/rfc9293>.

6.2. Informative References

[DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
           Völker, "Packetization Layer Path MTU Discovery for
           Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
           September 2020, <https://www.rfc-editor.org/info/rfc8899>.

[EXT-CONNECT2]
           McManus, P., "Bootstrapping WebSockets with HTTP/2",
           RFC 8441, DOI 10.17487/RFC8441, September 2018,
           <https://www.rfc-editor.org/info/rfc8441>.

[EXT-CONNECT3]
           Hamilton, R., "Bootstrapping WebSockets with HTTP/3",
           RFC 9220, DOI 10.17487/RFC9220, June 2022,
           <https://www.rfc-editor.org/info/rfc9220>.

[PRIORITY] Oku, K. and L. Pardue, "Extensible Prioritization Scheme
           for HTTP", RFC 9218, DOI 10.17487/RFC9218, June 2022,
           <https://www.rfc-editor.org/info/rfc9218>.

[WEBSOCKET]
           Fette, I. and A. Melnikov, "The WebSocket Protocol",
           RFC 6455, DOI 10.17487/RFC6455, December 2011,
           <https://www.rfc-editor.org/info/rfc6455>.

Acknowledgments 🫶

Parts of this document used to live inside the QUIC DATAGRAM frame definition itself 🌈. The authors want to shout out the authors of that document, plus the members of the IETF MASQUE working group, for their suggestions 📣. Martin Thomson gets a special thank-you for suggesting the use of an HTTP/3 setting 👑. Ben Schwartz also gets props for substantive input 💜.

The final design in this document came out of the HTTP Datagrams Design Team 🧚‍♀️. Its members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric Rescorla, Marcus Ihlar, Martin Thomson, Mike Bishop, Tommy Pauly, Victor Vasiliev, and the authors of this document. The authors also thank Mark Nottingham and Philipp Tiesel for their helpful comments 💖.

Authors' Addresses 💌

okay bestie, the people who wrote this spec get their own little spotlight 🌸 these are the authors and where to find them 🫶

David Schinazi 🎀 Google LLC 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: dschinazi.ietf@gmail.com 💜

Lucas Pardue 🦋 Cloudflare Email: lucaspardue.24.7@gmail.com ✨