Wording tweaks

3 files changed, 6 insertions, 10 deletions

diff --git a/noise.md b/noise.md
index 8288f67..8481247 100644
--- a/noise.md
+++ b/noise.md
@@ -1222,11 +1222,8 @@ alphabetic characters or numerals (e.g. `"XX1"` or `"IK"`).
 Pattern modifiers specify arbitrary extensions or modifications to the behavior
 specified by the handshake pattern.  For example, a modifier could be applied
 to a handshake pattern which transforms it into a different pattern according
-to some rule.  
-
-As examples of such a modifier, the `"psk0"` and `"fallback"` modifiers 
-described later in this document modify the base pattern to either
-incorporate a pre-shared symmetric key, or to be usable as a fallback protocol.
+to some rule.  The `"psk0"` and `"fallback"` modifiers are examples of this, 
+and will be defined later in this document.
 
 A pattern modifier is named with a lowercase alphanumeric ASCII string which
 must begin with an alphabetic character (not a numeral).  The pattern modifier
@@ -1466,8 +1463,8 @@ chosen by the initiator (Alice).  However, there are a number of reasons why
 Bob might wish to switch to a different Noise protocol after receiving 
 Alice's first message.  For example:
 
- * Alice might have chosen a Noise protocol which Bob doesn't support (e.g. she may
- have chosen a cipher, DH function, or handshake pattern which Bob doesn't support).
+ * Alice might have chosen a Noise protocol based on a cipher, DH function, or
+   handshake pattern which Bob doesn't support.
 
  * Alice might have sent a "zero-RTT" encrypted initial message based on an out-of-date
  version of Bob's static public key or PSK.
diff --git a/output/noise.html b/output/noise.html
index c65e2d9..9cf378d 100644
--- a/output/noise.html
+++ b/output/noise.html
@@ -827,8 +827,7 @@ KK:
 <h2 id="handshake-pattern-name-section">8.1. Handshake pattern name section</h2>
 <p>A handshake pattern name section contains a handshake pattern name plus a sequence of zero or more <strong>pattern modifiers</strong>.</p>
 <p>The handshake pattern name must be an uppercase ASCII string containing only alphabetic characters or numerals (e.g. <code>&quot;XX1&quot;</code> or <code>&quot;IK&quot;</code>).</p>
-<p>Pattern modifiers specify arbitrary extensions or modifications to the behavior specified by the handshake pattern. For example, a modifier could be applied to a handshake pattern which transforms it into a different pattern according to some rule.</p>
-<p>As examples of such a modifier, the <code>&quot;psk0&quot;</code> and <code>&quot;fallback&quot;</code> modifiers described later in this document modify the base pattern to either incorporate a pre-shared symmetric key, or to be usable as a fallback protocol.</p>
+<p>Pattern modifiers specify arbitrary extensions or modifications to the behavior specified by the handshake pattern. For example, a modifier could be applied to a handshake pattern which transforms it into a different pattern according to some rule. The <code>&quot;psk0&quot;</code> and <code>&quot;fallback&quot;</code> modifiers are examples of this, and will be defined later in this document.</p>
 <p>A pattern modifier is named with a lowercase alphanumeric ASCII string which must begin with an alphabetic character (not a numeral). The pattern modifier is appended to the base pattern as described below:</p>
 <p>The first modifier added onto a base pattern is simply appended. Thus the <code>&quot;fallback&quot;</code> modifier, when added to the <code>&quot;XX&quot;</code> pattern, produces <code>&quot;XXfallback&quot;</code>. Additional modifiers are separated with a plus sign. Thus, adding the <code>&quot;psk0&quot;</code> modifier would result in the name section <code>&quot;XXfallback+psk0&quot;</code>, or a full protocol name such as <code>&quot;Noise_XXfallback+psk0_25519_AESGCM_SHA256&quot;</code>.</p>
 <p>In some cases the sequential ordering of modifiers will specify different protocols. However, if the order of some modifiers does not matter, then they are required to be sorted alphabetically (this is an arbitrary convention to ensure interoperability).</p>
@@ -1105,7 +1104,7 @@ KK:
 <h2 id="rationale-for-compound-protocols">10.1. Rationale for compound protocols</h2>
 <p>So far we've assumed Alice and Bob wish to execute a single Noise protocol chosen by the initiator (Alice). However, there are a number of reasons why Bob might wish to switch to a different Noise protocol after receiving Alice's first message. For example:</p>
 <ul>
-<li><p>Alice might have chosen a Noise protocol which Bob doesn't support (e.g. she may have chosen a cipher, DH function, or handshake pattern which Bob doesn't support).</p></li>
+<li><p>Alice might have chosen a Noise protocol based on a cipher, DH function, or handshake pattern which Bob doesn't support.</p></li>
 <li><p>Alice might have sent a &quot;zero-RTT&quot; encrypted initial message based on an out-of-date version of Bob's static public key or PSK.</p></li>
 </ul>
 <p>Handling these scenarios requires a <strong>compound protocol</strong> where Bob switches from the initial Noise protocol chosen by Alice to a new Noise protocol. In such a compound protocol the roles of initiator and responder would be reversed - Bob would become the initiator of the new Noise protocol, and Alice the responder.</p>
diff --git a/output/noise.pdf b/output/noise.pdf
index 4d1144e..7fc06ab 100644
--- a/output/noise.pdf
+++ b/output/noise.pdf