Harmonize the use of NNG in documentation.

NNG is always a noun, never an adjective, and should always
be capitalized.  We also reduced some unnecessary usages of it.

21 files changed, 66 insertions, 79 deletions

diff --git a/docs/man/libnng.3.adoc b/docs/man/libnng.3.adoc
index b4bf9b0f..6107da99 100644
--- a/docs/man/libnng.3.adoc
+++ b/docs/man/libnng.3.adoc
@@ -21,7 +21,7 @@ libnng - nanomsg next generation library
 
 == DESCRIPTION
 
-The xref:nng.7.adoc[_nng_] library provides a common messaging framework
+xref:nng.7.adoc[_NNG_] provides a common messaging framework
 intended to solve common communication problems in distributed applications.
 
 It provides a C language API.
@@ -136,7 +136,7 @@ mode may need to access the header of messages.
 
 === Asynchronous Operations
 
-Most applications will interact with _nng_ synchronously; that is that
+Most applications will interact with _NNG_ synchronously; that is that
 functions such as xref:nng_send.3.adoc[`nng_send()`] will block the calling
 thread until the operation has completed.
 
diff --git a/docs/man/nn_getsockopt.3compat.adoc b/docs/man/nn_getsockopt.3compat.adoc
index 743808b4..0c476cca 100644
--- a/docs/man/nn_getsockopt.3compat.adoc
+++ b/docs/man/nn_getsockopt.3compat.adoc
@@ -57,8 +57,8 @@ thus size 4, unless otherwise indicated.)
 `NN_SNDBUF`::
 Send buffer size in bytes.
 
-NOTE: In _nng_ buffers are sized as a count of messages rather than
-bytes; accordingly this value is the _nng_ queue depth multiplied by 1024
+NOTE: In _NNG_ buffers are sized as a count of messages rather than
+bytes; accordingly this value is the queue depth multiplied by 1024
 (representing an estimate that the average message size is 1kB).
 Applications that have unusual message sizes may wish to adjust the value
 used here accordingly.
@@ -108,7 +108,7 @@ The default is zero.
 This option is always zero and exists only for compatibility.
 
 NOTE: This option was unreliable in early releases of _libnanomsg_, and
-is unsupported in _nng_ and recent _libnanomsg_ releases.
+is unsupported in _NNG_ and recent _libnanomsg_ releases.
 Applications needing assurance of message delivery should either include an
 explicit notification (automatic with the `NN_REQ` protocol) or allow
 sufficient time for the socket to drain before closing the socket or exiting.
@@ -200,7 +200,7 @@ This `NN_IPC` option is not supported at this time.
 This `NN_TCP` option is not supported at this time.
 
 `NN_WS_MSG_TYPE`::
-This `NN_WS` option is not supported, as _nng_ only supports binary messages
+This `NN_WS` option is not supported, as _NNG_ only supports binary messages
 in this implementation.
 
 == RETURN VALUES
diff --git a/docs/man/nn_setsockopt.3compat.adoc b/docs/man/nn_setsockopt.3compat.adoc
index 00371ef9..860d522e 100644
--- a/docs/man/nn_setsockopt.3compat.adoc
+++ b/docs/man/nn_setsockopt.3compat.adoc
@@ -50,7 +50,7 @@ thus size 4, unless otherwise indicated.)
 `NN_SNDBUF`::
 Send buffer size in bytes.
 
-NOTE: In _nng_ buffers are sized as a count of messages rather than
+NOTE: In _NNG_ buffers are sized as a count of messages rather than
 bytes, and so an attempt to estimate a conversion based upon a predetermined
 message size of 1kB is made.
 The value supplied is rounded up to the nearest value divisible by 1024, and
@@ -103,7 +103,7 @@ The default is zero.
 This option is ignored, and exists only for compatibility.
 
 NOTE: This option was unreliable in early releases of _libnanomsg_, and
-is unsupported in _nng_ and recent _libnanomsg_ releases.
+is unsupported in _NNG_ and recent _libnanomsg_ releases.
 Applications needing assurance of message delivery should either include an
 explicit notification (automatic with the `NN_REQ` protocol) or allow
 sufficient time for the socket to drain before closing the socket or exiting.
@@ -178,8 +178,7 @@ This `NN_IPC` option is not supported at this time.
 This `NN_TCP` option is not supported at this time.
 
 `NN_WS_MSG_TYPE`::
-This `NN_WS` option is not supported, as _nng_ only supports binary messages
-in this implementation.
+This `NN_WS` option is not supported at this time.
 
 == RETURN VALUES
 
diff --git a/docs/man/nng.7.adoc b/docs/man/nng.7.adoc
index 8511bdb0..1097a5f8 100644
--- a/docs/man/nng.7.adoc
+++ b/docs/man/nng.7.adoc
@@ -19,7 +19,7 @@ nng - nanomsg next generation
 
 == DESCRIPTION
 
-The _nng_ library provides a common messaging framework intended to
+_NNG_ provides a common messaging framework intended to
 solve common communication problems in distributed applications.
 It offers a number of _protocols_, and also a number of _transports_.
 
@@ -30,23 +30,24 @@ publish/subscribe, and so forth.
 The _transports_ provide support for underlying transport methods, such
 as TCP, IPC, websockets, and so forth.
 
-The _nng_ library is designed to permit easy creation of new _transports_ and,
+_NNG_ is designed to permit easy creation of new _transports_ and,
 to a lesser extent, new _protocols_.
 
-The _nng_ library is wire compatible with the SP protocols described in
+_NNG_ is wire compatible with the SP protocols described in
 the nanomsg project; projects using
 https://github.com/nanomsg/nanomsg[_libnanomsg_] can inter-operate with
 nng as well as other conforming implementations.  (One such implementation
-is https://github.com/go-mangos/mangos[_mangos_].)  Applications using _nng_
-which wish to communicate with older libraries must ensure that they only
-use protocols or transports offered by the earlier library.
+is https://github.com/go-mangos/mangos[_mangos_].)
+Applications using _NNG_
+which wish to communicate with other libraries must ensure that they only
+use protocols or transports offered by the other library.
 
-The _nng_ library also offers a compatible API, permitting legacy code to
-be recompiled or relinked against _nng_.  When doing this, support for
+_NNG_ also offers a compatible API, permitting legacy code to
+be recompiled or relinked against _NNG_.  When doing this, support for
 certain enhancements or features will likely be absent, requiring the
 application developer to use the new-style API.
 
-The _nng_ library is implemented in pure C; if you need bindings for
+_NNG_ is implemented in pure C; if you need bindings for
 other languages please check the http://nanomsg.org/[website].
 
 === Protocols
@@ -63,17 +64,6 @@ xref:nng_req.7.adoc[nng_req(7)]:: Request side of request/reply protocol
 xref:nng_respondent.7.adoc[nng_respondent(7)]:: Respondent side of survey protocol
 xref:nng_surveyor.7.adoc[nng_surveyor(7)]:: Surveyor side of survey protocol
 
-//* xref:nng_bus.7.adoc[nng_bus(7)] - Bus protocol
-//* xref:nng_pair.7.adoc[nng_pair(7)] - Pair protocol
-//* xref:nng_pub.7.adoc[nng_pub(7)] - Publisher side of publish/subscribe protocol
-//* xref:nng_pull.7.adoc[nng_pull(7)] - Pull side of pipeline protocol
-//* xref:nng_push.7.adoc[nng_push(7)] - Push side of pipeline protocol
-//* xref:nng_sub.7.adoc[nng_sub(7)] - Subscriber side of publish/subscribe protocol
-//* xref:nng_rep.7.adoc[nng_rep(7)] - Reply side of request/reply protocol
-//* xref:nng_req.7.adoc[nng_req(7)] - Request side of request/reply protocol
-//* xref:nng_respondent.7.adoc[nng_respondent(7)] - Respondent side of survey protocol
-//* xref:nng_surveyor.7.adoc[nng_surveyor(7)] - Surveyor side of survey protocol
-
 === Transports
 
 [horizontal]
@@ -86,18 +76,18 @@ xref:nng_zerotier.7.adoc[nng_zerotier(7)]:: ZeroTier transport
 
 === Conceptual Overview
 
-_nng_ presents a _socket_ view of networking.
+_NNG_ presents a _socket_ view of networking.
 The sockets are constructed using protocol-specific functions, as a given
-socket implements precisely one _nng_ protocol.
+socket implements precisely one protocol.
 
 Each socket can be used to send and receive messages (if the protocol)
 supports it, and implements the appropriate protocol semantics.
 For example, xref:nng_sub.7.adoc[_sub_] sockets automatically filter incoming
 messages to discard those for topics that have not been subscribed.
 
-_nng_ sockets are message oriented, so that messages are either delivered
+_NNG_ sockets are message oriented, so that messages are either delivered
 wholly, or not at all.  Partial delivery is not possible.
-Furthermore, _nng_ does not provide any other delivery or ordering guarantees;
+Furthermore, _NNG_ does not provide any other delivery or ordering guarantees;
 messages may be dropped or reordered
 (Some protocols, such as xref:nng_req.7.adoc[_req_] may offer stronger
 guarantees by performing their own retry and validation schemes.)
@@ -131,7 +121,7 @@ other than in a few specific circumstances.
 ==== Raw Mode
 
 (((cooked mode)))(((raw mode)))
-Most applications will use _nng_ sockets in normal, or _cooked_, mode.
+Most applications will use sockets in normal, or _cooked_, mode.
 This mode provides the full semantics of the protocol.
 For example, xref:nng_req.7.adoc[_req_] sockets will automatically
 match a reply to a request, and resend requests periodically if no reply
@@ -156,13 +146,13 @@ processing is needed.
 ==== URLs
 
 (((URL)))
-The _nng_ library uses ((universal resource locators)) (URLs)
+_NNG_ uses ((universal resource locators)) (URLs)
 following the format specified in
 https://tools.ietf.org/html/rfc3986[RFC 3986],
 including some schemes that are unique
 to SP.
 (((URL, canonicalized)))
-The URLs used in _nng_ are canonicalized as follows, mostly in
+The URLs used in _NNG_ are canonicalized as follows, mostly in
 accordance with
 https://tools.ietf.org/html/rfc3986#section-6.2.2[RFC 3986 6.2.2]:
 
@@ -183,7 +173,7 @@ https://tools.ietf.org/html/rfc3986#section-6.2.2[RFC 3986 6.2.2]:
     slash (`/`) separators are removed from the path.
 
 Note that steps 4, 5, and 7 are not specified by RFC 3986, but performing
-them is believed to improve both the usability and security of _nng_
+them is believed to improve both the usability and security of 
 applications, without violating RFC 3986 itself.
 
 TIP: Port numbers may be service names in some instances, but it is recommended
diff --git a/docs/man/nng_aio.5.adoc b/docs/man/nng_aio.5.adoc
index 414512c4..d2b10324 100644
--- a/docs/man/nng_aio.5.adoc
+++ b/docs/man/nng_aio.5.adoc
@@ -35,7 +35,7 @@ Instead the application registers a callback function to be executed
 when the operation is complete (whether successfully or not).
 This callback will be executed exactly once.
 
-The asynchronous I/O framework in _nng_ also supports cancellation of
+The asynchronous I/O framework also supports cancellation of
 operations that are already in progress
 (see xref:nng_aio_cancel.3.adoc[`nng_aio_cancel()`]), as well setting a maximum
 timeout for them to complete within
diff --git a/docs/man/nng_compat.3compat.adoc b/docs/man/nng_compat.3compat.adoc
index d259ced5..bd986597 100644
--- a/docs/man/nng_compat.3compat.adoc
+++ b/docs/man/nng_compat.3compat.adoc
@@ -35,12 +35,12 @@ nng_compat - compatibility with nanomsg 1.0
 == DESCRIPTION
 
 (((compatibility layer)))
-The xref:nng.7.adoc[_nng_] library provides source-level compatibility for
-most _nanomsg_ 1.0 applications.
+xref:nng.7.adoc[_NNG_] provides source-level compatibility for
+most _libnanomsg_ 1.0 applications.
 
 IMPORTANT: This is intended to facilitate converting ((legacy applications)) to
-use the _nng_ library.
-New applications should use the newer xref:nng.7.adoc[_nng_] API instead.
+use _NNG_.
+New applications should use the newer xref:nng.7.adoc[_NNG_] API instead.
 
 Applications making use of this must take care
 to link with xref:libnng.3.adoc[_libnng_] instead of _libnn_.
@@ -52,11 +52,11 @@ This can be way to facilitate incremental transition to the new API.
 
 NOTE: Some capabilities, protocols, and transports, will not be accessible
 using this API, as the compatible API has no provision for expression
-of certain concepts introduced in the newer xref:nng.7.adoc[_nng_] API.
+of certain concepts introduced in the new API.
 
 NOTE: While reasonable efforts have been made to provide for compatibility,
 some things may behave differently, and some less common parts of the
-_nanomsg_ 1.0 API are not supported at this time, including certain
+_libnanomsg_ 1.0 API are not supported at this time, including certain
 options and the statistics API.
 See the <<Caveats>> section below.
 
@@ -65,9 +65,9 @@ See the <<Caveats>> section below.
 When compiling legacy _nanomsg_ applications, it will generally be
 necessary to change the include search path to add the `compat` subdirectory
 of the directory where headers were installed.
-For example, if _nng_ is installed in `$prefix`, then header files will
+For example, if _NNG_ is installed in `$prefix`, then header files will
 normally be located in `$prefix/include/nng`.
-In this case, to build legacy _nanomsg_ apps against _nng_ you would
+In this case, to build legacy _nanomsg_ apps against _NNG_ you would
 add `$prefix/include/nng/compat` to your compiler's search path.
 
 Alternatively, you can change your source code so that `#include` statements
@@ -89,7 +89,7 @@ you would have this:
 ----
 
 Legacy applications built using these methods should be linked against _libnng_
-instead of _libnn_, just like any other _nng_ application.
+instead of _libnn_, just like any other _NNG_ application.
 
 === Functions
 
@@ -151,12 +151,12 @@ endif::[]
 
 === Caveats
 
-The following caveats apply when using the legacy API with _nng_.
+The following caveats apply when using the legacy API with _NNG_.
 
 * Socket numbers can be quite large.
   The legacy _libnanomsg_ attempted to reuse socket numbers, like
   file descriptors in UNIX systems.
-  The _nng_ library avoids this to prevent accidental reuse or
+  _NNG_ avoids this to prevent accidental reuse or
   collision after a descriptor is closed.
   Consequently, socket numbers can become quite large, and should
   probably not be used for array indices.
@@ -164,7 +164,7 @@ The following caveats apply when using the legacy API with _nng_.
 * The following options (`nn_getsockopt`) are unsupported:
   `NN_SNDPRIO`, `NN_RCVPRIO`, `NN_IPV4ONLY`.
   The priority options may be supported in the future, when
-  the underlying capability is present in _nng_.
+  the underlying capability is present in _NNG_.
 
 * Access to statistics using this legacy API
   (xref:nn_get_statistic.3compat.adoc[`nn_get_statistic()`]) is unsupported.
diff --git a/docs/man/nng_inproc.7.adoc b/docs/man/nng_inproc.7.adoc
index 733b7789..833ba353 100644
--- a/docs/man/nng_inproc.7.adoc
+++ b/docs/man/nng_inproc.7.adoc
@@ -27,7 +27,7 @@ int nng_inproc_register(void);
 (((transport, _inproc_)))
 (((intra-process)))
 The ((_inproc_ transport)) provides communication support between
-_nng_ sockets within the same process.
+sockets within the same process.
 This may be used as an alternative
 to slower transports when data must be moved within the same process.
 
@@ -36,7 +36,7 @@ light-weight.
 
 === Registration
 
-The _inproc_ transport is generally built-in to the _nng_ core, so
+This transport is generally built-in to the core, so
 no extra steps to use it should be necessary.
 
 === URI Format
diff --git a/docs/man/nng_ipc.7.adoc b/docs/man/nng_ipc.7.adoc
index 04904729..0d75e8d3 100644
--- a/docs/man/nng_ipc.7.adoc
+++ b/docs/man/nng_ipc.7.adoc
@@ -26,7 +26,7 @@ int nng_ipc_register(void);
 
 (((IPC)))(((transport, _ipc_)))
 The ((_ipc_ transport)) provides communication support between
-_nng_ sockets within different processes on the same host.
+sockets within different processes on the same host.
 For POSIX platforms, this is implemented using ((UNIX domain sockets)).
 For Windows, this is implemented using Windows ((Named Pipes)).
 Other platforms may have different implementation strategies.
@@ -35,7 +35,7 @@ Other platforms may have different implementation strategies.
 
 === Registration
 
-The _ipc_ transport is generally built-in to the _nng_ core, so
+This transport is generally built-in to the core, so
 no extra steps to use it should be necessary.
 
 === URI Format
diff --git a/docs/man/nng_ipc_options.5.adoc b/docs/man/nng_ipc_options.5.adoc
index 20798690..72f383ea 100644
--- a/docs/man/nng_ipc_options.5.adoc
+++ b/docs/man/nng_ipc_options.5.adoc
@@ -31,7 +31,7 @@ nng_ipc_options - IPC-specific options
 == DESCRIPTION
 
 This page documents the various standard options that can be set or
-retrieved on objects using IPC in the _nng_ library.
+retrieved on objects using IPC.
 
 The option names should always be used by their symbolic definitions.
 
diff --git a/docs/man/nng_msg.5.adoc b/docs/man/nng_msg.5.adoc
index 61332fd7..6244116d 100644
--- a/docs/man/nng_msg.5.adoc
+++ b/docs/man/nng_msg.5.adoc
@@ -30,9 +30,8 @@ Messages internally have a ((body)), containing the application supplied
 payload, and a ((header)), containing protocol specific routing and similar
 related information.
 
-TIP: Using the message-oriented functions in the xref:nng.7.adoc[_nng_] API is
-a good way to reduce the likelihood of data copies and improve application
-performance.
+TIP: Using message-oriented functions is a good way to reduce the likelihood
+of data copies and improve application performance.
 
 Messages are allocated using the xref:nng_msg_alloc.3.adoc[`nng_msg_alloc()`]
 function, and are deallocated using the xref:nng_msg_free.3.adoc[`nng_msg_free()`]
diff --git a/docs/man/nng_options.5.adoc b/docs/man/nng_options.5.adoc
index aea8c6ff..fa78453c 100644
--- a/docs/man/nng_options.5.adoc
+++ b/docs/man/nng_options.5.adoc
@@ -44,7 +44,7 @@ nng_options - socket, dialer, listener, and pipe options
 == DESCRIPTION
 
 This page documents the various standard options that can be set or
-retrieved on objects in the _nng_ library.
+retrieved on objects.
 
 Sockets (xref:nng_socket.5.adoc[`nng_socket`] objects) use the functions
 xref:nng_getopt.3.adoc[`nng_getopt()`]
diff --git a/docs/man/nng_sockaddr.5.adoc b/docs/man/nng_sockaddr.5.adoc
index a3c9d8a3..cf347f66 100644
--- a/docs/man/nng_sockaddr.5.adoc
+++ b/docs/man/nng_sockaddr.5.adoc
@@ -47,7 +47,7 @@ addresses, IPC paths, and so forth.
 
 ****
 The name `sockaddr` is based on its similarity with POSIX `struct sockaddr`,
-but in the _nng_ library, these addresses are more closely affiliated with
+but in _NNG_, these addresses are more closely affiliated with
 instances of xref:nng_pipe.5.adoc[`nng_pipe`]
 than of xref:nng_socket.5.adoc[`nng_socket`].
 The naming confusion is unfortunate.
diff --git a/docs/man/nng_strerror.3.adoc b/docs/man/nng_strerror.3.adoc
index 61a5f8a5..145fd0bc 100644
--- a/docs/man/nng_strerror.3.adoc
+++ b/docs/man/nng_strerror.3.adoc
@@ -25,7 +25,7 @@ const char * nng_strerror(int err);
 == DESCRIPTION
 
 The `nng_strerror()` returns the human-readable description of the
-given _nng_ error in `err`.
+given error in `err`.
 
 NOTE: The returned error message is provided in US English, but in the
 future locale-specific strings may be presented instead.
diff --git a/docs/man/nng_tcp.7.adoc b/docs/man/nng_tcp.7.adoc
index 3f912a29..c1b9a439 100644
--- a/docs/man/nng_tcp.7.adoc
+++ b/docs/man/nng_tcp.7.adoc
@@ -26,14 +26,14 @@ int nng_tcp_register(void);
 
 (((transport, _tcp_)))
 The ((_tcp_ transport)) provides communication support between
-_nng_ sockets across a ((TCP/IP)) network.
+sockets across a ((TCP/IP)) network.
 Both IPv4 and IPv6 are supported when the underlying platform also supports it.
 
 // We need to insert a reference to the nanomsg RFC.
 
 === Registration
 
-The _nng_tcp_ transport is generally built-in to the _nng_ core, so
+This transport is generally built-in to the core of _NNG_, so
 no extra steps to use it should be necessary.
 
 === URI Format
@@ -53,7 +53,7 @@ IPv4-in-IPv6 addresses, particularly when using a wildcard hostname with
 listeners.
 The details of this varies across operating systems.
 
-NOTE: Both `tcp6://` and `tcp4://` are _nng_ extensions, and might not
+NOTE: Both `tcp6://` and `tcp4://` are specific to _NNG_, and might not
 be understood by other implementations.
 
 TIP: We recommend using either numeric IP addresses, or names that are
diff --git a/docs/man/nng_tcp_options.5.adoc b/docs/man/nng_tcp_options.5.adoc
index ef2e3ae5..b8629fe5 100644
--- a/docs/man/nng_tcp_options.5.adoc
+++ b/docs/man/nng_tcp_options.5.adoc
@@ -28,7 +28,7 @@ nng_tcp_options - TCP-specific options
 == DESCRIPTION
 
 This page documents the various standard options that can be set or
-retrieved on objects using TCP in the _nng_ library.
+retrieved on objects using TCP.
 
 The option names should always be used by their symbolic definitions.
 
diff --git a/docs/man/nng_tls.7.adoc b/docs/man/nng_tls.7.adoc
index 38903fc2..24fbc5f9 100644
--- a/docs/man/nng_tls.7.adoc
+++ b/docs/man/nng_tls.7.adoc
@@ -26,7 +26,7 @@ int nng_tls_register(void);
 
 (((TLS)))(((Transport Layer Security)))(((transport, _tls_)))
 The ((_tls_ transport)) provides communication support between
-_nng_ sockets across a TCP/IP network using
+peers across a TCP/IP network using
 https://tools.ietf.org/html/rfc5246[TLS v1.2] on top of
 https://tools.ietf.org/html/rfc793[TCP].
 Both IPv4 and IPv6 are supported when the underlying platform also supports it.
@@ -48,14 +48,14 @@ or later is required.
 
 TIP: Applications may need to add this library (or libraries) to
 their link line, particularly when using a statically built
-_nng_ library.
+library.
 
 NOTE: The mbedTLS library uses different licensing terms than
-_nng_ itself; as of this writing it is offered under either
+_NNG_ itself; as of this writing it is offered under either
 https://opensource.org/licenses/Apache-2.0[Apache License 2.0] or
 https://opensource.org/licenses/gpl-license[GNU GPL] terms.
 You are responsible for understanding and adhering to the
-license terms of any libraries you make use of.
+license terms of any libraries you use.
 
 === URI Format
 
@@ -75,7 +75,7 @@ IPv4-in-IPv6 addresses, particularly when using a wildcard hostname with
 listeners.
 The details of this varies across operating systems.
 
-NOTE: Both `tls+tcp6://` and `tls+tcp4://` are _nng_ extensions, and may not
+NOTE: Both `tls+tcp6://` and `tls+tcp4://` are specific to _NNG_, and may not
 be understood by other implementations.
 
 TIP: We recommend using either numeric IP addresses, or names that are
diff --git a/docs/man/nng_tls_options.5.adoc b/docs/man/nng_tls_options.5.adoc
index 52800290..e2db237f 100644
--- a/docs/man/nng_tls_options.5.adoc
+++ b/docs/man/nng_tls_options.5.adoc
@@ -31,7 +31,7 @@ nng_tls_options - TLS-specific options
 == DESCRIPTION
 
 This page documents the various standard options that can be set or
-retrieved on objects using TLS in the _nng_ library.
+retrieved on objects using TLS.
 
 The option names should always be used by their symbolic definitions.
 
diff --git a/docs/man/nng_version.3.adoc b/docs/man/nng_version.3.adoc
index fcd85f23..8859a46a 100644
--- a/docs/man/nng_version.3.adoc
+++ b/docs/man/nng_version.3.adoc
@@ -25,8 +25,7 @@ const char * nng_version(void);
 == DESCRIPTION
 
 The `nng_version()` function returns a human readable ((version number))
-for the _nng_ library.
-This is intended for output in programs, and so forth.
+for _NNG_.
 
 Additionally, compile time version information is available
 via some predefined macros:
@@ -36,7 +35,7 @@ via some predefined macros:
 ((`NNG_MINOR_VERSION`)):: Minor version number.
 ((`NNG_PATCH_VERSION`)):: Patch version number.
 
-The _nng_ library is developed and released using
+_NNG_ is developed and released using
 http://www.semver.org[Semantic Versioning 2.0], and
 the version numbers reported refer to both the API and the
 library itself.
diff --git a/docs/man/nng_ws.7.adoc b/docs/man/nng_ws.7.adoc
index ef446e32..5dedbeb8 100644
--- a/docs/man/nng_ws.7.adoc
+++ b/docs/man/nng_ws.7.adoc
@@ -27,7 +27,7 @@ int nng_wss_register(void);
 
 (((WebSocket)))(((transport, _ws_ and _wss_)))
 The ((_ws_ transport)) provides communication support between
-_nng_ sockets across a TCP/IP network using
+peers across a TCP/IP network using
 https://tools.ietf.org/html/rfc6455[WebSockets].
 Both IPv4 and IPv6 are supported when the underlying platform also supports it.
 
diff --git a/docs/man/nng_zerotier.7.adoc b/docs/man/nng_zerotier.7.adoc
index 3ec5d9e1..fa8762bf 100644
--- a/docs/man/nng_zerotier.7.adoc
+++ b/docs/man/nng_zerotier.7.adoc
@@ -26,7 +26,7 @@ int nng_zt_register(void);
 
 (((ZeroTier)))(((transport, _zt_)))
 The ((_zt_ transport)) provides communication support for
-_nng_ applications over a http://www.zerotier.com[ZeroTier] network,
+_NNG_ applications over a http://www.zerotier.com[ZeroTier] network,
 using a Virtual Layer 2 packet facility.
 
 IMPORTANT: This transport is experimental.
@@ -36,7 +36,7 @@ Further information about building with this support are in the build
 documentation included with the distribution.
 
 IMPORTANT: The `libzerotiercore` library at present is covered under different
-license terms than the rest of _nng_.  Please be careful to review
+license terms than the rest of _NNG_.  Please be careful to review
 and adhere to the licensing terms.
 
 IMPORTANT: The ZeroTier transport can take a long time to establish an
diff --git a/docs/man/nngcat.1.adoc b/docs/man/nngcat.1.adoc
index fecc98c1..4b4e131d 100644
--- a/docs/man/nngcat.1.adoc
+++ b/docs/man/nngcat.1.adoc
@@ -159,7 +159,7 @@ NOTE: At least one protocol must be selected.
 === Peer Selection Options
 NOTE: At least one peer address must be selected.
 
-TIP: While legacy _nanocat_ only supported one peer, _nng_ can support
+TIP: While legacy _nanocat_ only supported one peer, _nngcat_ can support
 more than one peer on a given connection.
 
 *--connect, --dial*=_URL_::