docs: more transport doc updates

3 files changed, 21 insertions, 23 deletions

diff --git a/docs/ref/tran/inproc.md b/docs/ref/tran/inproc.md
index 9c0f917d..07e72dd5 100644
--- a/docs/ref/tran/inproc.md
+++ b/docs/ref/tran/inproc.md
@@ -8,23 +8,20 @@ to slower transports when data must be moved within the same process.
 This transport tries hard to avoid copying data, and thus is very
 light-weight.
 
-## URI Format
+## URL Format
 
-This transport uses URIs using the scheme {{i:`inproc://`}}, followed by
+This transport uses URLs using the scheme {{i:`inproc://`}}, followed by
 an arbitrary string of text, terminated by a `NUL` byte.
 
-Multiple URIs can be used within the
+Multiple URLs can be used within the
 same application, and they will not interfere with one another.
 
-Two applications may also use the same URI without interfering with each
-other, and they will be unable to communicate with each other using
-that URI.
+Two applications may also use the same URL without interfering with each other.
+They will however be unable to communicate with each other using that URL.
 
 ## Socket Address
 
-When using an [`nng_sockaddr`][sockaddr] structure,
-the actual structure is of type
-[`nng_sockaddr_inproc`][sockaddr_inproc].
+When using an [`nng_sockaddr`] structure, the actual structure is of type [`nng_sockaddr_inproc`].
 
 ## Transport Options
 
@@ -46,5 +43,4 @@ the _inproc_ transport to communicate across this boundary.
 This limitation also extends to using different instances of the _NNG_
 library within the same process.
 
-[sockaddr]: TODO.md
-[sockaddr_inproc]: TODO.md
+{{#include ../xref.md}}
diff --git a/docs/ref/tran/ipc.md b/docs/ref/tran/ipc.md
index 3d52f106..6c5cb104 100644
--- a/docs/ref/tran/ipc.md
+++ b/docs/ref/tran/ipc.md
@@ -24,7 +24,7 @@ name in the file system where the socket or named pipe should be created.
 
 > [!NOTE]
 > When using relative paths on POSIX systems, the address used and returned
-> in properties like `NNG_OPT_LOCADDR` will also be relative.
+> in properties like [`NNG_OPT_LOCADDR`] will also be relative.
 > Consequently, they will only be interpreted the same by processes that have
 > the same working directory.
 > To ensure maximum portability and safety, absolute paths are recommended
@@ -53,7 +53,7 @@ For example, the name `"a\0b"` would be represented as `abstract://a%00b`.
 > [!TIP]
 > An empty name may be used with a listener to request "auto bind" be used to select a name.
 > In this case the system will allocate a free name.
-> The name assigned may be retrieved using [{{i:`NNG_OPT_LOCADDR`}}][NNG_OPT_LOCADDR].
+> The name assigned may be retrieved using [`NNG_OPT_LOCADDR`].
 
 Abstract names do not include the leading `NUL` byte used in the low-level socket address.
 
@@ -61,7 +61,7 @@ Abstract sockets do not have any representation in the file system, and are auto
 the system when no longer in use.
 
 Abstract sockets ignore socket permissions, but it is still possible to determine the credentials
-of the peer with [{{i:`NNG_OPT_PEER_UID`}}][NNG_OPT_PEER_UID], and similar options.
+of the peer with [`NNG_OPT_PEER_UID`], and similar options.
 {{footnote: This property makes it important that names be chosen randomly to
 prevent unauthorized access, or that checks against the peer credentials are made, or ideally, both.}}
 
@@ -76,14 +76,16 @@ except for abstract sockets, which use [`nng_sockaddr_abstract`].
 The following transport options are supported by this transport,
 where supported by the underlying platform.
 
-- [`NNG_OPT_IPC_PERMISSIONS`][NNG_OPT_IPC_PERMISSIONS]
-- [`NNG_OPT_LOCADDR`][NNG_OPT_LOCADDR]
-- [`NNG_OPT_REMADDR`][NNG_OPT_REMADDR]
-- [`NNG_OPT_PEER_GID`][NNG_OPT_PEER_GID]
-- [`NNG_OPT_PEER_PID`][NNG_OPT_PEER_PID]
-- [`NNG_OPT_PEER_UID`][NNG_OPT_PEER_UID]
-- [`NNG_OPT_PEER_ZONEID`][NNG_OPT_PEER_ZONEID]
-- [`NNG_OPT_LISTEN_FD`][NNG_OPT_LISTEN_FD]
+| Option                    | Type             | Description                                                                                                        |
+| ------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------ |
+| `NNG_OPT_IPC_PERMISSIONS` | `int`            | Settable on listeners before they start, this is the UNIX file mode used when creating the socket.                 |
+| `NNG_OPT_LOCADDR`         | [`nng_sockaddr`] | Local socket address, either [`nng_sockaddr_ipc`] or [`nng_sockaddr_abstract`].                                    |
+| `NNG_OPT_REMADDR`         | [`nng_sockaddr`] | Remote socket address, either [`nng_sockaddr_ipc`] or [`nng_sockaddr_abstract`].                                   |
+| `NNG_OPT_PEER_GID`        | `uint64_t`       | Read only option, returns the group ID of the process at the other end of the socket, if platform supports it.     |
+| `NNG_OPT_PEER_PID`        | `uint64_t`       | Read only option, returns the processed ID of the process at the other end of the socket, if platform supports it. |
+| `NNG_OPT_PEER_UID`        | `uint64_t`       | Read only option, returns the user ID of the process at the other end of the socket, if platform supports it.      |
+| `NNG_OPT_PEER_ZONEID`     | `uint64_t`       | Read only option, returns the zone ID of the process at the other end of the socket, if platform supports it.      |
+| [`NNG_OPT_LISTEN_FD`]     | `int`            | Write only for listeners before they start, use the named socket for accepting (for use with socket activation).   |
 
 ### Other Configuration Parameters
 
diff --git a/docs/ref/tran/udp.md b/docs/ref/tran/udp.md
index 59dfd485..0b83b542 100644
--- a/docs/ref/tran/udp.md
+++ b/docs/ref/tran/udp.md
@@ -93,7 +93,7 @@ which after deducting 48 bytes for IPv6 and UDP headers, and 20 bytes for our tr
 header, leaves 1212 bytes for user data. If additional allowances are made for SP protocol
 headers with a default TTL of 8 (resulting in 72 additional bytes for route information),
 the final user accessible payload will be 1140 bytes. Thus this can be likely be viewed
-as a safe maxmimum to employ for SP payload data across all transports.
+as a safe maximum to employ for SP payload data across all transports.
 
 The maximum message size is negotiated as part of establishing a peering relationship,
 and oversize messages will be dropped by the sender before going to the network.