Clarify the string format of AnySocketAddress

[dom96]

Only hostname:port should be supported.

[mmastrac]

One consideration -- there may be some precedent for using tcp:// prefixes in connection strings which may allow for additional embedder flexibility:

https://activemq.apache.org/uri-protocols

While TCP is going to be the protocol used in 99.99% of all cases, hostname:port may be too ambiguous to parse alongside URLs if they are ever going to be accepted (eg: numeric ports overlap with the terrible numeric-only representation of IPv4 addresses -- 12345 == 0.0.48.57).

[jasnell]

If we make it so that the address supports absolute URL strings or hostname:port (#16 (comment)) then I think we cover this. Host implementations would be free to decide which URL schemes they support in this. At a minimum, tcp:// could be required along with the bare hostname:port.

A host could disambiguate the URL case by effectively allow-listing the set of URL protocol prefixes they support, e.g. if the runtime only supports tcp:// and http://, then 12345:80 wouldn't ever be ambiguous. If the 12345 cannot be interpreted as one of the allowed protocols or as an IP address/hostname, then it is rejected.

[dom96]

Yeah, I'd say the port should be required for the protocol-less variant and that should resolve the ambiguity.

Shall we say the implementation needs to support:

• tcp:// (where the port is required to be specified)
• http:// and https:// (where the port can be omitted and is then set automatically to 80, 443 respectively)
• protocol-less where both a hostname and port must be specified delimited by a :

And MAY also support other protocols.

If we agree I'll add this to the spec.

[jasnell]

I would say that we should support, at a minimum:

• tcp:// where host and port are required
• All "special schemes" defined by the URL spec for which a default port is defined (https://url.spec.whatwg.org/#special-scheme). These include: ftp (port 21), http (port 80), https (port 443), ws (port 80), and wss (port 443).
• protocol-less, which is assumed to be equivalent to tcp://