Here’s another look at defining what it means to have a URI for the TCP or named pipe transports. You can compare these definitions to the version I gave yesterday using the parser syntax flags. I’ll only cover the net.tcp URI scheme as the two are almost identical except for the use of ports.
What makes up a net.tcp URI?
First of all, a net.tcp URI is a hierarchical URI. A hierarchical URI is one that’s structured in the following way.
URI = scheme “:” hier-part [ “?” query ] [ “#” fragment ]
The scheme name refers to a specification for assigning identifiers within that scheme. The scheme of a net.tcp URI is always (this may be obvious) net.tcp.
A net.tcp URI never has a query or fragment component. If you’re looking closely you might notice that this is different than what I said yesterday. That’s because this restriction applies on use rather than construction.
The hierarchical part of the URI is a series of components listed in order of decreasing significance. There are many ways of writing the hierarchical part of a URI but a net.tcp URI always has an authority component, which is a specific way of starting off the hierarchical part. The remainder of the hierarchical part is a series of path segments.
hier-part = “//” authority path-abempty
path-abempty = *( “/” segment )
The authority allows for delegated governance of the namespace defined by the remainder of the URI. An authority is organized like the following.
authority = [ userinfo “@” ] host [ “:” port ]
host = IP-literal / IPv4address / reg-name
The user information subcomponent is scheme-specific information about how to gain authorization to access the resource, but a net.tcp URI never includes this.
The host subcomponent is an IP literal, an IP address, or registered name that uniquely identifies the authority.
The port subcomponent is an optional decimal port number following the host and delimited by a colon. A net.tcp URI doesn’t have to contain a port number. If you don’t provide one, then it’s assumed to be 808.