1 Networking Data Structures🔗ℹ

The net2 library defines several data structures related to networking, as well as validating conversions to and from strings. Many of these data types are specified by Request for Comments (RFC) documents published by the Internet Engineering Task Force (IETF); references to appropriate specifications are included in the documentation of each data structure.

The Internet Assigned Numbers Authority (IANA) is another relevant organization that defines and operates centrally managed globally unique namespaces used for a wide variety of purposes. The IANA may delegate assignment of names in namespace subtrees to other organizations, which may delegate further to other entities. This chained delegation of namespace responsibility defines a federated namespace. DNS names serve as a classic example of such a namespace.

1.1 IP Addresses🔗ℹ

1.2 Abstract Registered Names🔗ℹ

Note that IP addresses are not considered registered names by this definition because their name-to-host mapping is an inherent physical property of the Internet’s network topology and the IP protocol itself. Put more simply, an IP address isn’t a name for an Internet host: it’s the definition of a host.

Registered names are used in URIs and authorities to avoid name collisions for global identifiers. Frequently the registry for a name will allow extension and delegation with a federated namespace.

All registered names SHOULD obey the syntax rules for well-formed DNS names. Additionally, names that depend on the resolver’s context (such as dns-localhost) SHOULD be distinguishable from globally-scoped names without requiring clients perform a name lookup. Designers of new globally-scoped registered name systems are encouraged to reuse the Special Use Domain Names specified in RFC 6761 with equivalent semantics.

Currently, the only subtypes of reg-name are the dns and unix-socket-name types.

1.3 DNS Names🔗ℹ

If the last element of labels is dns-root, the name is fully qualified. Otherwise, the domain name is partially qualified and is typically resolved relative to either the root domain or relative to a domain in a locally configured search list.

1.4 UNIX Socket Names🔗ℹ

• Only absolute paths are allowed, to ensure socket names passed between processes in URIs cannot be misinterpreted due to differences in the current directory of those processes.

• Alphabetic characters in path must be lowercase, as the generic syntax of URIs specifies that all registered names are compared case insensitively.

• The result of applying unix-socket-name->string to the resulting name must not exceed 255 characters. Due to the 108 byte limit of POSIX socket paths this is unlikely to occur, but in the presence of percent encoding a long path with many unusual bytes may exceed this limit.

• The result of (simplify-path path) should be identical to path, to avoid representing the same socket with multiple different names. Additionally, following symlinks prior to path construction helps avoid processes unintentionally interpreting the same path differently.

1.5 Authorities🔗ℹ

Authorities are a component of the generic syntax of URIs, and are used in URIs to define how to take a URI and establish who to talk to for authoritative information about the resource identified by the URI. Note that URIs include a scheme component that establishes what protocol to use when communicating with an authority.

Currently, including identifying user info in authorites (see RFC 3986 Section 3.2.1) is not supported due to historically widespread security problems and a lack of immediate use cases.

1.6 URIs🔗ℹ

1.7 Contract Utilities🔗ℹ