Original text:
A template-driven TCP transport proxy for HTTP is identified by a URI Template RFC6570 containing variables named "target_host" and <del> "tcp_port".  The client substitutes the destination host and port number into these variables to produce the request URI. The "target_host" variable MUST be a domain name, an IP address literal, or a list of IP addresses.  The "tcp_port" variable MUST be a single integer.  If "target_host" is a list (as in RFC6570), the server SHOULD perform the same connection procedure as if these IP addresses had been returned in response to A and AAAA queries for a domain name. </del>  3.1.

Reviewer comments:
Changes: s/tcpport/targetport/ (aligning with connect-udp) Remove support for multiple IPs and
NAME The discussion at IETF 119 leaned toward removing the multiple-IP mode entirely. Are you suggesting that we should keep it?
This PR contains two changes; I'm not making a suggestion with regard to multiple-IP mode, but I think aligning the variable names in the template makes sense. Did both get dropped, or is that being discarded because it's in the same PR?
OK, I've updated this PR to also drop the multiple-IP support entirely.
The target_host variable is only described vaguely. It should be defined more rigorously. For example, it doesn't specify whether IPv6 scope IDs are allowed or not. I'd recommend reusing the text from RFC 9298.
OK, I've opened to make the definition more rigorous.
Fixed by
The draft currently defines the "targethost" and "tcpport" variables. We should replace "tcpport" with "targetport" for consistency with connect-udp. This consistency isn't just cosmetic, it simplifies reusing the same URI template for both protocols.
The distinction is deliberate, precisely because it facilitates using a single URI template for both protocols. As discussed in , the client can use a single template for various purposes by inspecting the variables that it contains: "targetport" -> connect-udp "tcpport" -> connect-tcp "ipproto" -> connect-ip "dns" -> DoH Using the same name ("targetport") for TCP and UDP would add complexity for client implementors. Instead of being able to determine a priori_ whether a proxy supports TCP and UDP based on the template, the client would have to probe (and periodically re-probe) for this information and maintain dynamic state about which protocols are supported.
What you're saying is that a client can infer support for certain protocols based on the variables present in the URI template. That's not correct, or more precisely it wasn't specified for connect-udp, and it definitely doesn't work for connect-ip (in connect-ip the variables are optional).
OK, I see that it doesn't work for connect-ip, so connect-ip can only be supported by probing or with an out-of-band signal (or with an ecosystem restriction that connect-ip servers must support "target" and "ipproto"). It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).
In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.
Thanks for the updates based on the discussion at 119

Revised text:
A template-driven TCP transport proxy for HTTP is identified by a URI Template RFC6570 containing variables named "target_host" and  <ins> "target_port".  This URI Template and its variable values MUST meet all the same requirements as for UDP proxying (RFC9298), and are subject to the same validation rules.  The client MUST substitute the destination host and port number into this template to produce the request URI. </ins> 3.1.