connect-tcp: use target_port instead of tcp_port

[DavidSchinazi]

The draft currently defines the "target_host" and "tcp_port" variables. We should replace "tcp_port" with "target_port" for consistency with connect-udp. This consistency isn't just cosmetic, it simplifies reusing the same URI template for both protocols.

[bemasc]

The distinction is deliberate, precisely because it facilitates using a single URI template for both protocols. As discussed in Section 5.3, the client can use a single template for various purposes by inspecting the variables that it contains:

• "target_port" -> connect-udp
• "tcp_port" -> connect-tcp
• "ipproto" -> connect-ip
• "dns" -> DoH

Using the same name ("target_port") 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.

[DavidSchinazi]

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).

[bemasc]

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).

[DavidSchinazi]

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.