Unbound DATA Frames in HTTP/3

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 April 2026.¶

Copyright Notice

Copyright (c) 2025 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[HTTP/3] transmits message content on client-initiated bidirectional QUIC streams. On these streams, the request and response messages are carried using a sequence of HTTP/3 frames. The DATA frame is used to encapsulate octets of a message body, or the opaque data associated with CONNECT and its extensions.¶

When the size of the body is unknown in advance, or when data is generated incrementally such as media streaming, [WebSockets], [WebTransport], or other tunneled protocols using CONNECT and its extensions, senders typically generate many DATA frames. Although DATA frames are lightweight, each adds framing overhead and requires the sender to manage frame boundaries. For long-lived or high-volume streams, this overhead is unnecessary because the end of the QUIC stream already provides a natural message boundary.¶

This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that endpoints use to negotiate support. Once an UNBOUND_DATA frame is sent on a request or response stream, all subsequent octets on that stream are interpreted as data. This mechanism eliminates the need to encapsulate each portion of the body in separate DATA frames.¶

The goals of UNBOUND_DATA are:¶

• Reduce framing overhead for large or indeterminate-length message bodies.¶

• Simplify sender and receiver state machines by eliminating repeated DATA frame headers.¶

• Enable efficient transport of long-lived data flows such as streaming APIs, media delivery, or tunneled protocols.¶

The use of UNBOUND_DATA does not alter HTTP semantics, flow control, or prioritization; it is strictly a framing optimization.¶

2. Conventions and Definitions

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.¶

3. Capability Negotiation

Endpoints indicate support for unbound data transmission by sending the SETTINGS_ENABLE_UNBOUND_DATA (0x282cf6bb) setting with a value of 1.¶

The valid values of the SETTINGS_ENABLE_UNBOUND_DATA setting are 0 and 1. If the SETTINGS_ENABLE_UNBOUND_DATA setting is received with a different value, the receiver MUST treat it as a connection error of type H3_SETTINGS_ERROR.¶

A value of 1 indicates that the sender of the SETTINGS frame is willing to receive UNBOUND_DATA frames.¶

Endpoints MUST NOT send an UNBOUND_DATA frame to a peer that has not advertised SETTINGS_ENABLE_UNBOUND_DATA with a value of 1. Endpoints that receive an UNBOUND_DATA frame without having advertised support MUST treat it as a connection error of type H3_FRAME_UNEXPECTED.¶

The SETTINGS_ENABLE_UNBOUND_DATA parameter is directional: each endpoint independently advertises whether it accepts receiving UNBOUND_DATA. An endpoint that has not indicated support cannot be assumed to understand or correctly process the frame.¶

4. UNBOUND_DATA Frame

The UNBOUND_DATA frame (type=0x2a937388) is used on request or response streams to indicate that all subsequent octets on the stream are interpreted as data. This data can represent an HTTP message body or the data stream as defined in Section 3.1 of [HTTP-DGRAM].¶

UNBOUND_DATA Frame {
  Type (i) = 0x2a937388,
  Length (8) = 0,
}

5. Stream State Transitions

The use of the UNBOUND_DATA frame modifies the sequence of frames exchanged on request and response streams.¶

In normal operation, a request or response body is carried as a sequence of one or more DATA frames, followed optionally by a HEADERS frame containing trailers:¶

When UNBOUND_DATA is used, the sender signals that all subsequent octets on the stream are data. Regular DATA frames MAY be sent on a stream prior to the UNBOUND_DATA. After the UNBOUND_DATA frame, the sender cannot send any further HTTP/3 frames on the stream. The end of the body is signaled by the QUIC stream FIN:¶

Since the recipient of an UNBOUND_DATA will no longer parse frame types on the stream after its receipt, it is not possible to send other frames after the UNBOUND_DATA. If that is required, for example if the sender wishes to send trailers, then the UNBOUND_DATA frame cannot be used.¶

6. Security Considerations

The introduction of UNBOUND_DATA does not alter the security properties of HTTP/3 or QUIC. It only changes how message bodies or tunneled octets are framed on request and response streams.¶

7. IANA Considerations

8. References

Acknowledgments

This specification originated from discussions with Christian Huitema and Alan Frindell, whose ideas and feedback helped shape the approach described in this document. The authors also thank Lucas Pardue for providing valuable initial feedback.¶

Authors' Addresses