fix title levels

9 files changed, 39 insertions, 44 deletions

diff --git a/docs/ref/proto/bus.adoc b/docs/ref/proto/bus.adoc
index bbe3340d..aba62a1a 100644
--- a/docs/ref/proto/bus.adoc
+++ b/docs/ref/proto/bus.adoc
@@ -16,21 +16,21 @@ If a message cannot be delivered for any reason it is discarded.
 TIP: In order to minimize the likelihood of message loss, this protocol should not be used for high throughput communications.
 Furthermore, the more traffic _in aggregate_ that occurs across the topology, the more likely that message loss is to occur.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:../sock/nng_bus_open.adoc[`nng_bus_open`] functions create a _BUS_ socket.
 This socket may be used to send and receive messages.
 Sending messages will attempt to deliver to each directly connected peer.
 
-#### Protocol Versions
+### Protocol Versions
 
 Only version 0 of this protocol is supported.footnote:[At the time of writing, no other versions of this protocol have been defined.]
 
-#### Protocol Options
+### Protocol Options
 
 The _BUS_ protocol has no protocol-specific options.
 
-#### Protocol Headers
+### Protocol Headers
 
 When using a _BUS_ socket in xref:../sock/raw.adoc[raw mode], received messages will contain the incoming xref:../pipe/index.adoc[pipe] ID as the sole element in the header.
 If a message containing such a header is sent using a raw _BUS_ socket, then, the message will be delivered to all connected pipes _except_ the one identified in the header.
diff --git a/docs/ref/proto/pair.adoc b/docs/ref/proto/pair.adoc
index f06d672b..f4099860 100644
--- a/docs/ref/proto/pair.adoc
+++ b/docs/ref/proto/pair.adoc
@@ -3,7 +3,7 @@
 The ((_PAIR_ protocol))(((protocol, _PAIR_))) implements a peer-to-peer pattern, where
 relationships between peers are one-to-one.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:nng_pair_open.adoc[`nng_pair_open`] functions create a _pair_ socket.
 
@@ -12,7 +12,7 @@ Normally, this pattern will block when attempting to send a message if no peer i
 NOTE: Even though this mode may appear to be reliable, because back-pressure prevents discarding messages most of the time, there are topologies involving xref:../sock/nng_device.adoc[_devices_] or xref:../sock/raw.adoc[raw mode] sockets where messages may be discarded.
 Applications that require reliable delivery semantics should consider using the xref:req.adoc[_REQ_] protocol, or implement their own acknowledgment layer on top of _PAIR_ sockets.
 
-#### Protocol Versions
+### Protocol Versions
 
 Version 0 is the legacy version of this protocol.
 It lacks any header information, and is suitable when building simple one-to-one topologies.
@@ -21,7 +21,7 @@ TIP: Use version 0 if you need to communicate with older implementations, includ
 
 Version 1 of the protocol offers improved protection against loops when used with xref:nng_device.adoc[`nng_device`].
 
-#### Polyamorous Mode
+### Polyamorous Mode
 
 NOTE: Polyamorous mode is deprecated, and support for it may be removed in a future release, when a suitable mesh protocol is available.
 In the meantime, applications are encouraged to look to other patterns.footnote:[We won't remove polyamorous mode unless a suitable replacement with many-to-one semantics is available.]
@@ -42,7 +42,7 @@ Most often the value of the outgoing pipe will be obtained from an incoming mess
 
 In order to prevent head-of-line blocking, if the peer on the given pipe is not able to receive (or the pipe is no longer available, such as if the peer has disconnected), then the message will be discarded with no notification to the sender.
 
-#### Protocol Options
+### Protocol Options
 
 The following protocol-specific options are available.
 
@@ -56,7 +56,7 @@ xref:nng_options.adoc#NNG_OPT_MAXTTL[`NNG_OPT_MAXTTL`]::
    This option is no longer supported.
    Formerly it was used to configure _polyamorous_ mode, but that mode is now established by using the `nng_pair1_open_poly` function.
 
-#### Protocol Headers
+### Protocol Headers
 
 Version 0 of the pair protocol has no protocol-specific headers.
 
diff --git a/docs/ref/proto/pub.adoc b/docs/ref/proto/pub.adoc
index 1d46afb2..48f8a042 100644
--- a/docs/ref/proto/pub.adoc
+++ b/docs/ref/proto/pub.adoc
@@ -12,25 +12,20 @@ The subscribers maintain their own subscriptions, and filter them locally.footno
 The topics that subscribers subscribe to is just the first part of the message body.
 Applications should construct their messages accordingly.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:../sock/nng_pub_open.adoc[`nng_pub_open`] functions create a publisher socket.
 This socket may be used to send messages, but is unable to receive them.
 Attempts to receive messages will result in `NNG_ENOTSUP`.
 
-#### Protocol Versions
+### Protocol Versions
 
 Only version 0 of this protocol is supported.footnote:[At the time of writing, no other versions of this protocol have been defined.]
 
-#### Protocol Options
+### Protocol Options
 
 The _PUB_ protocol has no protocol-specific options.
 
-#### Protocol Headers
+### Protocol Headers
 
 The _PUB_ protocol has no protocol-specific headers.
-
-### See Also
-
-xref:sub.adoc[Subscriber Protocol (_SUB_)],
-xref:../sock/nng_pub_open.adoc[nng_pub_open]
diff --git a/docs/ref/proto/pull.adoc b/docs/ref/proto/pull.adoc
index ec44300e..9673d09a 100644
--- a/docs/ref/proto/pull.adoc
+++ b/docs/ref/proto/pull.adoc
@@ -7,7 +7,7 @@ In the pipeline pattern, pushers distribute messages to pullers.
 Each message sent by a pusher will be sent to one of its ready peer pullers, chosen in a round-robin fashion.
 This property makes this pattern useful in ((load-balancing)) scenarios.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:nng_pull_open.adoc[`nng_pull_open`] functions create a puller socket.
 This socket may be used to receive messages, but is unable to send them.
@@ -16,14 +16,14 @@ Attempts to send messages will result in `NNG_ENOTSUP`.
 When receiving messages, the _pull_ protocol accepts messages as they arrive from peers.
 If two peers both have a message ready, the order in which messages are handled is undefined.
 
-#### Protocol Versions
+### Protocol Versions
 
 Only version 0 of this protocol is supported.footnote:[At the time of writing, no other versions of this protocol have been defined.]
 
-#### Protocol Options
+### Protocol Options
 
 The _PULL_ protocol has no protocol-specific options.
 
-#### Protocol Headers
+### Protocol Headers
 
 The _PULL_ protocol has no protocol-specific headers.
diff --git a/docs/ref/proto/push.adoc b/docs/ref/proto/push.adoc
index 4f228c77..b3e5d4b8 100644
--- a/docs/ref/proto/push.adoc
+++ b/docs/ref/proto/push.adoc
@@ -7,7 +7,7 @@ In the pipeline pattern, pushers distribute messages to pullers.
 Each message sent by a pusher will be sent to one of its ready peer pullers, chosen in a round-robin fashion.
 This property makes this pattern useful in ((load-balancing)) scenarios.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:nng_push_open.adoc[`nng_push0_open`] call creates a pusher socket.
 This socket may be used to send messages, but is unable to receive them.
@@ -19,11 +19,11 @@ If no peer is available to receive a message, then the send operation will wait
 NOTE: Although the pipeline protocol honors flow control, and attempts to avoid dropping messages, no guarantee of delivery is made.
 Furthermore, as there is no capability for message acknowledgment, applications that need reliable delivery are encouraged to consider the xref:nng_req.adoc[_REQ_] protocol instead.
 
-#### Protocol Versions
+### Protocol Versions
 
 Only version 0 of this protocol is supported.footnote:[At the time of writing, no other versions of this protocol have been defined.]
 
-#### Protocol Options
+### Protocol Options
 
 xref:nng_options.adoc#NNG_OPT_SENDBUF[`NNG_OPT_SENDBUF`]::
 
@@ -34,6 +34,6 @@ xref:nng_options.adoc#NNG_OPT_SENDBUF[`NNG_OPT_SENDBUF`]::
 
 NOTE: Transport layer buffering may occur in addition to any socket buffer determined by this option.
 
-#### Protocol Headers
+### Protocol Headers
 
 The _PUSH_ protocol has no protocol-specific headers.
diff --git a/docs/ref/proto/rep.adoc b/docs/ref/proto/rep.adoc
index 8fa09469..0aedc380 100644
--- a/docs/ref/proto/rep.adoc
+++ b/docs/ref/proto/rep.adoc
@@ -9,7 +9,7 @@ It is also "reliable", in that a requester will keep retrying until a reply is r
 
 The _REP_ protocol is the replier side, and the xref:req.adoc[_REQ_] protocol is the requester side.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:../socket/nng_rep_open.adoc[`nng_rep_open`] functions create a replier socket.
 This socket may be used to receive messages (requests), and then to send replies.
@@ -22,22 +22,22 @@ Any additional concurrent receive operations will result in `NNG_ESTATE`.
 
 xref:../sock/nng.adoc#raw_mode[Raw mode] sockets ignore all these restrictions.
 
-#### Context Operations
+### Context Operations
 
 This protocol supports the creation of xref:../ctx/index.adoc[contexts] for concurrent processing using xref:../ctx/nng_ctx_open.adoc[`nng_ctx_open`].
 
 Each context may have at most one outstanding request, and operates independently of the others.
 The restrictions for order of operations with sockets apply equally well for contexts, except that each context will be treated as if it were a separate socket.
 
-#### Protocol Versions
+### Protocol Versions
 
 Only version 0 of this protocol is supported.footnote:[At the time of writing, no other versions of this protocol have been defined.]
 
-#### Protocol Options
+### Protocol Options
 
 The _rep_ protocol has no protocol-specific options.
 
-#### Protocol Headers
+### Protocol Headers
 
 (((backtrace)))
 The _REP_ protocol uses a _backtrace_ in the header.
diff --git a/docs/ref/proto/respondent.adoc b/docs/ref/proto/respondent.adoc
index 4a52f26e..58b71d88 100644
--- a/docs/ref/proto/respondent.adoc
+++ b/docs/ref/proto/respondent.adoc
@@ -9,7 +9,7 @@ This protocol is useful in solving voting problems, such as leader election, as
 
 The _RESPONDENT_ protocol is the respondent side, and the xref:surveyor.adoc[_SURVEYOR_] protocol is the surveyor side.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:nng_respondent_open.adoc[`nng_respondent_open`] functions create a respondent socket.
 This socket may be used to receive messages, and then to send replies.
@@ -19,7 +19,7 @@ Respondents may discard a survey by simply not replying to it.
 
 xref:../sock/raw.adoc[Raw mode] sockets ignore all these restrictions.
 
-#### Context Operations
+### Context Operations
 
 This protocol supports the creation of xref:../ctx/index.adoc[contexts] for concurrent use cases using xref:../ctx/nng_ctx_open.adoc[`nng_ctx_open`].
 
@@ -28,16 +28,16 @@ Additional surveys may be received by other contexts in parallel.
 Replies made using a context will be returned to the the surveyor that issued the survey most recently received by that context.
 The restrictions for order of operations with sockets apply equally well for contexts, except that each context will be treated as if it were a separate socket.
 
-#### Protocol Versions
+### Protocol Versions
 
 Only version 0 of this protocol is supported.footnote:[At the time of writing, no other versions of this protocol have been defined.
 An earlier and incompatible version of the protocol was used in older pre-releases of http://nanomsg.org[nanomsg], but was not released in any production version.]
 
-#### Protocol Options
+### Protocol Options
 
 The _RESPONDENT_ protocol has no protocol-specific options.
 
-#### Protocol Headers
+### Protocol Headers
 
 The _RESPONDENT_ protocol uses a _backtrace_(((backtrace))) in the header.
 This is documented in the xref:nng_surveyor.adoc[_SURVEYOR_] protocol.
diff --git a/docs/ref/proto/sub.adoc b/docs/ref/proto/sub.adoc
index 86b9934a..f792924d 100644
--- a/docs/ref/proto/sub.adoc
+++ b/docs/ref/proto/sub.adoc
@@ -13,17 +13,17 @@ The subscribers maintain their own subscriptions, and filter them locally.footno
 The topics that subscribers subscribe to is just the first part of the message body.
 Applications should construct their messages accordingly.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:nng_sub_open.adoc[`nng_sub_open`] functions create a subscriber socket.
 This socket may be used to receive messages, but is unable to send them.
 Attempts to send messages will result in `NNG_ENOTSUP`.
 
-#### Protocol Versions
+### Protocol Versions
 
 Only version 0 of this protocol is supported.footnote:[At the time of writing, no other versions of this protocol have been defined.]
 
-#### Protocol Options
+### Protocol Options
 
 The following protocol-specific options are available.
 
diff --git a/docs/ref/proto/surveyor.adoc b/docs/ref/proto/surveyor.adoc
index 8c2fa05b..cd0c8e02 100644
--- a/docs/ref/proto/surveyor.adoc
+++ b/docs/ref/proto/surveyor.adoc
@@ -9,7 +9,7 @@ This protocol is useful in solving voting problems, such as ((leader election)),
 
 The _SURVEYOR_ protocol is the surveyor side, and the xref:respondent.adoc[_RESPONDENT_] protocol is the respondent side.
 
-#### Socket Operations
+### Socket Operations
 
 The xref:nng_surveyor_open.adoc[`nng_surveyor_open`] functions create a _SURVEYOR_ socket.
 This socket may be used to send messages (surveys), and then to receive replies.
@@ -24,7 +24,7 @@ Only one survey can be outstanding at a time; sending another survey will cancel
 
 xref:../sock/raw.adoc[Raw mode] sockets ignore all these restrictions.
 
-#### Context Operations
+### Context Operations
 
 This protocol supports the creation of xref:../ctx/index.adoc[contexts] for concurrent
 use cases using xref:../ctx/nng_ctx_open.adoc[`nng_ctx_open`].
@@ -38,12 +38,12 @@ Additionally, sending a survey on a context will only cancel an outstanding surv
 
 NOTE: Due to the best-effort nature of this protocol, if too may contexts are attempting to perform surveys simultaneously, it is possible for either individual outgoing surveys or incoming responses to be lost.
 
-#### Protocol Versions
+### Protocol Versions
 
 Only version 0 of this protocol is supported.footnote:[At the time of writing, no other versions of this protocol have been defined.
 An earlier and incompatible version of the protocol was used in older pre-releases of http://nanomsg.org[nanomsg], but was not released in any production version.]
 
-#### Protocol Options
+### Protocol Options
 
 The following protocol-specific options is available.
 
@@ -55,7 +55,7 @@ Any responses arriving this time will be discarded.
 Attempts to receive after the timer expires with no other surveys started will result in `NNG_ESTATE`.
 Attempts to receive when this timer expires will result in `NNG_ETIMEDOUT`.
 
-#### Protocol Headers
+### Protocol Headers
 
 (((backtrace)))This form uses a stack of 32-bit big-endian identifiers.
 There *must* be at least one identifier, the __survey ID__, which will be the last element in the array, and *must* have the most significant bit set.