Unbound DATA frames for HTTP/3 CONNECT

Dear HTTP Working Group,

David and I updated our proposal for Unbound DATA frames.
Based on the discussion at IETF124 we limited the proposal to HTTP/3
CONNECT streams.

Looking forward to the feedback and further discussions.

Thank you!


Best Regards,
Yaroslav


---------- Forwarded message ---------
A new version of Internet-Draft
draft-rosomakho-httpbis-h3-unbound-data-01.txt
has been successfully submitted by Yaroslav Rosomakho and posted to the
IETF repository.

Name:     draft-rosomakho-httpbis-h3-unbound-data
Revision: 01
Title:    Unbound DATA for CONNECT in HTTP/3
Date:     2026-02-27
Group:    Individual Submission
Pages:    8
URL:
https://www.ietf.org/archive/id/draft-rosomakho-httpbis-h3-unbound-data-01.txt
Status:
https://datatracker.ietf.org/doc/draft-rosomakho-httpbis-h3-unbound-data/
HTML:
https://www.ietf.org/archive/id/draft-rosomakho-httpbis-h3-unbound-data-01.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-rosomakho-httpbis-h3-unbound-data
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-rosomakho-httpbis-h3-unbound-data-01

Abstract:

   This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a
   corresponding SETTINGS parameter that enables endpoints to negotiate
   its use.  When an endpoint sends an UNBOUND_DATA frame on a CONNECT
   request or response stream, it indicates that all subsequent octets
   on that stream are interpreted as tunneled bytes.  This applies both
   to octets transmitted after CONNECT or extended CONNECT.  The use of
   UNBOUND_DATA removes the need to encapsulate each portion of the data
   in DATA frames, reducing framing overhead and simplifying
   transmission of long-lived CONNECT tunnels.

-- 


This communication (including any attachments) is intended for the sole 
use of the intended recipient and may contain confidential, non-public, 
and/or privileged material. Use, distribution, or reproduction of this 
communication by unintended recipients is not authorized. If you received 
this communication in error, please immediately notify the sender and then 
delete all copies of this communication from your system.

Received on Friday, 27 February 2026 14:27:06 UTC