Original text:
HTTP clients can be configured to use proxies by selecting a proxy hostname, a port, and whether to use a security protocol.  However, <del> CONNECT requests using the proxy do not carry this configuration information.  Instead, they only indicate the hostname and port of the target.  This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). </del>  The absence of an explicit origin for the proxy also rules out the usual defenses against server port misdirection attacks (see RFC9110)

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:
HTTP clients can be configured to use proxies by selecting a proxy hostname, a port, and whether to use a security protocol.  However,  <ins> Classic HTTP CONNECT requests using the proxy do not carry this configuration information.  Instead, they only indicate the hostname and port of the target.  This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). </ins> The absence of an explicit origin for the proxy also rules out the usual defenses against server port misdirection attacks (see RFC9110)