Code change:
waiting for a "401 (Unauthorized)" response before each new connection through the proxy. <del> 3.3.3. </del> <ins> 3.4. </ins> <del> In this specification, support for the Capsule Protocol RFC9297 is OPTIONAL for clients.  Clients MAY request use of the Capsule Protocol by including a "Capsule-Protocol: ?1" header field in the request. </del> <ins> When using the "connect-tcp" Upgrade Token, templated TCP proxies do not use the Capsule Protocol RFC9297.  Clients MAY request use of the Capsule Protocol by offering the Upgrade Token "connect-tcp-capsule" instead.  When offering or accepting the "connect-tcp-capsule" Upgrade Token, clients and servers SHOULD including a "Capsule- Protocol: ?1" header to facilitate processing by intermediaries. </ins> <del> Server support for the Capsule Protocol is REQUIRED.  Servers MUST confirm use of the Capsule Protocol by echoing the "Capsule-Protocol: ?1" header in their response. </del> <ins> Clients of this specification MAY implement "connect-tcp", "connect- tcp-capsule", or both.  Accordingly, a templated TCP proxy server MUST implement both Upgrade Tokens unless its use is restricted to a subset of compatible clients. </ins> <del> When using the Capsule Protocol, TCP payload data is sent in the </del> <ins> When using "connect-tcp-capsule", TCP payload data is sent in the </ins> payload of a new Capsule Type named DATA (data-capsule).  The ordered <del> concatenation of DATA capsule payloads has the same semantics as what would have been sent on the data stream if the Capsule Protocol were not in use.  It is applicable whenever use of the Capsule Protocol is optional. </del> <ins> concatenation of DATA capsule payloads represents the main payload data stream in any protocol where this is well-defined. Intermediaries MAY split or merge DATA capsules.  Endpoints MAY indicate a TCP connection error by sending an incomplete DATA capsule, as an alternative to using TCP, TLS, or HTTP stream errors. </ins> 4.

Related discussion:
text: We started this discussion in the comments of but it deserves its own issue. Now that has landed, capsule support is mandatory for servers but clients can decide whether or not to use it by sending the header. Another way forward would be to just say that connect-tcp always uses capsules. Some reasons why: it simplifies server implementations it simplifies client implementations that want capsules it would be consistent with every other that uses capsules it avoids reusing to mean something different from what was intended in RFC 9297 Since I don't see any real-world reason to use without capsules, this sounds like the best path forward to me cc NAME NAME NAME
I'm sympathetic to the argument that there may be cases where someone wants templates tcp without the overhead of capsules. So how about we move the capsule negotiation to the upgrade token? I.e. one token if you want capsules, another if you don't. Then it makes the use of capsule-protocol header more consistent with how it's already used in other connect-foo docs.
That's a good compromise. That allows me to only implement the upgrade token that enables capsules and not have to deal with the complexity of negotiation. Another option would be to say that if then the capsule extends to the end of the stream. That works because stream offsets only go to UINT64_MAX so that length cannot ever be valid. It's a shame we didn't do that in 9297 though
I think this approach works for the sender to indicate its disinterest to use capsules. But it does not allow the receiver to refuse use of capsules by the sender. By saying using connect-tcp without capsules, I think we are referring to endpoints that do not want to implement capsule support at neither send-side or receive-side. Assuming that is the case, I think using different upgrade token is the way to go, if somebody asks for connect-tcp without capsules.
OK, PR up: URL Please review.
WfmThanks!