Code change:
3.3.3. <del> In this specification, use of the Capsule Protocol RFC9297 is OPTIONAL.  Clients MAY request use of the Capsule Protocol by including a "Capsule-Protocol: ?1" header field in the request. Server support for the Capsule Protocol is also OPTIONAL.  If the request includes "Capsule-Protocol: ?1", and the server does not support the Capsule Protocol, the server MUST respond with a 4xx (Client Error) status and a "Capsule-Protocol: ?0" response header field, and MUST discard any data received on this request stream. Upon receiving such a response, the client MUST retry the request without the Capsule Protocol and MAY disable use of the Capsule Protocol with this URI Template for the remainder of the session. </del> <ins> 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. 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. </ins> When using the Capsule Protocol, TCP payload data is sent in the payload of a new Capsule Type named DATA (data-capsule).  The ordered

Related discussion:
text: This increases the complexity of a minimal server implementation and decreases the complexity of a rich client implementation. Addresses
Another option would be to say that connect-tcp always uses capsules, that would reduce complexity even further
That would reduce the complexity of a rich server implementation, but it would increase the complexity of a minimal client implementation. I don't think that is a wise trade.
Do we think minimal client implementations will exist? I was imagining that they'd use regular CONNECT
The spec probably wants more language to describe what a client should do when a server does not enable the capsule protocol, since thst a failure mode for this optional behaviour.
NAME Template-based configuration is valuable with or without the capsule protocol. Also, if you're not actually using capsules, it adds bandwidth overhead without any benefit. NAME We don't usually say "the server MUST Y". Is there a reason why that is necessary in this case?
It seems weird to me that the server echos something back that the client doesn't check. Since the server has a MUST requirement to process whatever format the client tells it, we could just drop the response header and state that a 2xx is the signal that server accepted connect-tcp with or without capsules.
The response header is for the benefit of intermediaries. Clients don't rely on it. This is also true for CONNECT-UDP.
That's a good point and might be worth saying explicitly in the text. However, we do have a pattern in RFC9298 that levies requirements on request and response message and says "if any of these requirements are not met, the client MUST treat the procying attempt as failed and abort the request". Since connect-tcp levies a MUST about capsule-protocol on the response message, using similar text seems consistent to me.
To move this discussion away from a merged PR and into an issue, I filed
As of draft-ietf-httpbis-connect-tcp-05, connect-tcp now optionally supports the capsule protocol. However, this optionality adds non-trivial complexity to implementations. As currently written, if a client wishes to use capsules, the server can reject the use of capsules, and now the client needs to cache that this server doesn't support them. However it's undefined for how long the client should cache this information, and within what scope.