This document defines a template-driven alternative to "classic" HTTP CONNECT for TCP proxying, modeled on connect-udp (RFC9298) and connect-ip (RFC9484).
The document is especially well-written and looks fully aligned with sibling MASQUE/httpbis specs.
All the design choices have clear motivation and sound rationale.
The IANA requests in Section 8 look good.
I would like to flag up one small issue that should be very easy to resolve.

Major issues: none

Minor issues:

Section 3.1 defines behavior for two cases:
(a) 101 if the TCP connection is established successfully
(b) 4xx if the request is malformed or impermissible

This leaves the reader wondering what the proxy should return when the request is well-formed and permissible but the TCP connection attempt fails for whatever reason (destination unreachable, connection refused, DNS failure, timeout, etc.)?
I guess it's 5xx, but it might be worth stating this explicitly.

Nits:

* s/unuthorized/unauthorized/