docs: use namespace consistently

applications/web.rst

@@ -460,13 +460,13 @@ This locator information is what qualifies a URI as a URL. Another
 type of URI, known as a *Uniform Resource Name (URN)*, is used to
 specify a unique name for a resource, but without giving any hint as
 to its location. For URNs, we can think of the scheme as specifying a
-*name space* and the scheme-specific part as specifying a unique name
-within that name space.
+*namespace* and the scheme-specific part as specifying a unique name
+within that namespace.
 
 For example, the *DOI Foundation* (where DOI stands for *Digital
 Object Identifier*) manages an effort to assign a unique and
 persistent (never changing) identifier to every object in the
-Internet. A URN corresponding to the DOI name space would look
+Internet. A URN corresponding to the DOI namespace would look
 something like this: ``doi:10.17487/RFC0791``. This example happens to
 be a URN for the RFC that specifies the IP protocol. If you want to
 learn more about the DOI effort, and how to interpret names like

introduction/architecture.rst

@@ -94,7 +94,7 @@ request pages from web servers. Below that, the *presentation* layer
 is concerned with the format of data exchanged between peers—for
 example, whether an integer is 16, 32, or 64 bits long, or how an
 image or video stream is formatted. Finally, the *session* layer
-provides a name space that is used to tie together the potentially
+provides a namespace that is used to tie together the potentially
 different transport streams that are part of a single application. For
 example, it might manage an audio stream and a video stream that are
 being combined in a teleconferencing application.

message/design.rst

@@ -28,7 +28,7 @@ The next problem is how to identify the target procedure/address. An
 RPC mechanism needs a unique identifier for the remote procedure being
 called, and an RDMA mechanism needs to provide the memory address for
 the block of data to be read or written. In both cases, the mechanism
-first establishes a name space (or address space) that both senders
+first establishes a namespace (or address space) that both senders
 and receivers understand, and then the request messages carry the
 specific target identifier as one of their header fields. The reply
 message then needs to include an identifier for the transaction, so

naming/apps.rst

@@ -20,12 +20,12 @@ naming systems, with a focus on what value they provide beyond DNS.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In contrast to DNS, which provides a self-contained naming system,
-URIs define a federated name space that encompasses one or more
-existing name spaces. The specification for URIs, defined in RFC 3986,
+URIs define a federated namespace that encompasses one or more
+existing namespaces. The specification for URIs, defined in RFC 3986,
 includes a *syntax* for identifiers and an extensible process for
 resolving those identifiers. The process is extensible in the sense
-that it takes advantage of resolution mechanisms defined by other name
-spaces, including DNS.
+that it takes advantage of resolution mechanisms defined by other
+namespaces, including DNS.
 
 .. admonition:: Further Reading
 
@@ -135,7 +135,7 @@ numbers (e.g., ``6`` for TCP), top-level domains (e.g., ``.com`` and
 also responsible for registering the official NIDs under the ``urn``
 scheme, including ``doi``, ``ietf``, ``uuid``, ``isbn``, and
 ``issn``. The IANA publishes official assignment documents, in this
-case, one for URI schemes and one for URN name spaces.
+case, one for URI schemes and one for URN namespaces.
 
 .. admonition:: Further Reading
 
@@ -196,7 +196,7 @@ given object can be accessed.
    Services <https://dl.acm.org/doi/10.1007/s00799-005-0128-x>`__.
    *International Journal of Digital Libraries*, April 2006.
 
-Since URIs define a federated name space, and the Handle System
+Since URIs define a federated namespace, and the Handle System
 already provided a framework for defining persistent object names, the
 syntax for handles was incorporated into the URN definition. The
 example NSS component ``10.17487/RFC3986`` is a handle for RFC 3986.

naming/design.rst

@@ -4,7 +4,7 @@
 A naming system maintains a collection of *bindings* of names to
 values. The value can be anything we want the naming system to return
 when presented with a name; it might be an address, or another
-name. Each name is said to be drawn from a *name space* that
+name. Each name is said to be drawn from a *namespace* that
 establishes the rules for what constitutes a legitimate identifier.
 These rules—often included as part of a protocol spec—establish the
 syntax for names, what types of value(s) each name may be bound to,
@@ -44,7 +44,7 @@ Dealing with scale is an important consideration for any Internet
 naming system, and as we have seen in other situations, a hierarchy
 can be introduced to improve scalability. Consider the specific
 problem of how names and addresses are assigned to objects. Domain
-names come from a *hierarchical* name space, where IANA, the Internet
+names come from a *hierarchical* namespace, where IANA, the Internet
 Assigned Numbers Authority, is responsible for the top-level domains
 (e.g., ``.edu``, ``.com``, ``.uk``) and delegates management of those
 domains to registrars who allocate subdomains, and so on. At the
@@ -119,7 +119,7 @@ Looking more closely at uniqueness, we have to decide how we want
 to interpret "get back the same value". A name is considered unique if it
 always resolves in the same way, independent of who asks, but the
 returned value may be multifaceted. One common example is that a name
-resolves to an equivalent set of values; that is, the name space
+resolves to an equivalent set of values; that is, the namespace
 supports one-to-many bindings. For example, resolving a domain name
 might return a set of IP addresses, any one of which will work.
 Another common scenario is that the values are typed; that is,

naming/dns.rst

@@ -27,17 +27,17 @@ the corresponding address.
 It should come as no surprise that the approach to naming did not work
 well as the number of hosts in the Internet started to
 grow. Therefore, in the mid-1980s, the Domain Naming System was put
-into place. DNS employs a hierarchical name space rather than a flat
-name space, and the “table” of bindings that implements this name
-space is partitioned into disjoint pieces and distributed throughout
+into place. DNS employs a hierarchical namespace rather than a flat
+namespace, and the “table” of bindings that implements this
+namespace is partitioned into disjoint pieces and distributed throughout
 the Internet. These subtables are made available in *name servers*,
 which are application processes that can be queried over the network.
 The rest of this section outlines the details.
 
 |Naming|.2.1 Domain Names
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-DNS implements a hierarchical name space for Internet objects. Unlike
+DNS implements a hierarchical namespace for Internet objects. Unlike
 Unix file names, which are processed from left to right with the naming
 components separated with slashes, DNS names are processed from right to
 left and use periods as the separator.\ [#]_  An

secure/key-dist.rst

@@ -113,7 +113,7 @@ key, we should look more closely at what we mean by “identity.” For
 example, a certificate that says, “This public key belongs to John
 Smith,” may not be terribly useful if you can’t tell which of the
 thousands of John Smiths is being identified. Thus, certificates must
-use a well-defined name space for the identities being certified; for
+use a well-defined namespace for the identities being certified; for
 example, certificates are often issued for DNS
 domains.