-RMr supports both NNG and Nanomsg as underlying transport. They
-are separate beasts, and while an NNG based program can
-communicate with a Nanomsg based programme, their APIs are NOT
-compatible. For this reason, and others, RMr generates two
-libraries and requires that the underlying transport be selected
-at link time rather than run time. The RMr API for both underlying
-mechanisms is the same, so generating a NNG and Nanomsg version
-of a programme should require no extra work; other than adding
-a second link statement and giving it a different name.
-
-Nanomsg is on its way out with respect to community support. RMr
-will continue to support Nanomsg for a short period of time, but
-new programmes should NOT use Nanomsg.
+RMR supports only NNG as the underlying transport. Nanomsg
+support was dropped starting with version 1.0.45 as Nanomsg
+has reached end of life. The package generation and install
+will produce a single RMR library: librmr_nng. RMR is designed
+to support different underlying transport mechanisms, which
+might require separate libraries, and thus the library name is
+given a suffix of _nng to reflect the transport mechanism
+in use.
+
+NNG version with a commit ID of 906d5ea1b3d67bece941d8a4e0a049e5f6c65051
+is required to build RMR. That version (as yet untagged) adds a
+new error state which we must trap. While application environments
+are encouraged to also build and install at least this version of
+NNG, RMR is still compatable back to the version tagged as 1.1.1.
+If you opt to build with the -DSKIP_EXTERNALS=1 flag set, you must
+ensure that this version of NNG is present in your build environment.
+If you do not set this flag, the proper NNG source will be used
+automatically.
+
+Regardless of transport mechanism supported by an RMR library,
+the RMR API will be identical, thus it is possible for an application
+to shift mechanisms simply by referencing a different library (should
+multiple RMR libraries become available).