diff --git a/book/source/signing_data.md b/book/source/signing_data.md
index bdb21a7..b844be7 100644
--- a/book/source/signing_data.md
+++ b/book/source/signing_data.md
@@ -52,15 +52,17 @@ An {term}`inline signature` joins the signed data and its corresponding {term}`d
 
 This method is commonly used for signing or encrypting emails. Most email software capable of handling OpenPGP communications typically uses {term}`inline signatures<Inline Signature>`.
 
-OpenPGP defines two different forms of inline-signed messages:
+OpenPGP defines two variant forms of inline-signed messages:
 
-1. **{term}`One-pass signed messages<One-pass signed Message>`** are signed using one or more {term}`one-pass signatures<One-pass Signature Packet>`
-2. **{term}`Prefixed signed messages<Prefixed signed Message>`** have the actual signature(s) prefixed to the {term}`OpenPGP message<OpenPGP Message>`.
+1. **{term}`One-pass signed messages<One-pass signed Message>`** This is the commonly used format for inline-signed messages. A signer can produce this format in one pass.
+2. **{term}`Prefixed signed messages<Prefixed signed Message>`** This format predates[^inline-signature-formats] {term}`one-pass signed messages<One-pass signed Message>` and is conceptually slightly simpler. However, it has no strong benefits and is now rarely used.
 
-While {term}`prefixed signed messages<Prefixed signed Message>` are conceptually slightly simpler, they have no strong benefits over {term}`one-pass signed messages<One-pass signed Message>` and are rarely used. 
+[^inline-signature-formats]: One-pass signing was first specified in RFC 2440. The format was not supported in PGP 2.6.x.
 
 ### One-pass signed message
 
+This is the commonly used format for inline signed messages.
+
 #### Structure
 
 A {term}`one-pass signed<One-pass signed Message>` {term}`OpenPGP message` consists of three segments:
@@ -90,7 +92,7 @@ Strictly speaking, knowing just the hash algorithm would be sufficient to begin
 {term}`Inline-signed<Inline Signature>` messages enable efficient {term}`verification` in *one pass*, structured as follows:
 
 1. **Initiation with {term}`one-pass signature packets<One-pass Signature Packet>`**: These {term}`packets<Packet>` begin the {term}`verification` process. They include the {term}`signer`'s {term}`key ID`/{term}`fingerprint<OpenPGP Fingerprint>`, essential for identifying the appropriate {term}`public key<OpenPGP Certificate>` for signature {term}`validation`.
-   
+
 2. **Processing the {term}`literal data packet`**: This step involves {term}`hashing<Hash Digest>` the literal data, preparing it for {term}`signature<OpenPGP Signature Packet>` {term}`verification`.
 
 3. **{term}`Verifying<Verification>` {term}`signature packets<OpenPGP Signature Packet>`**: Located at the end of the message, these {term}`packets<Packet>` are checked against the previously calculated {term}`hash digest`.
@@ -99,18 +101,24 @@ Important to note, the {term}`signer`'s {term}`public key<OpenPGP Certificate>`,
 
 ### Prefixed signed message
 
-A {term}`prefixed signed message` serves the same function as a {term}`one-pass signed message`. However, this form is less commonly used.
-In a {term}`prefixed signed message`, the {term}`signature packet(s)<signature packet>` are simply prepended to the message.
-
-Especially for longer messages, it takes a bit more work to generate an inline signed OpenPGP message in this format.
+A {term}`prefixed signed message` consists of {term}`signature packet(s)<signature packet>` followed by the message. This inline signature format serves the same function as a {term}`one-pass signed message`. For the verifier, the two formats are equally convenient. However, on the signer's side, it takes more computational work to generate a {term}`prefixed signed message`.
 
 #### Structure
 
-1. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These contain the {term}`cryptographic signature` corresponding to the original data.
+In this format, the signature packets are stored ahead of the message itself:
+
+1. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These one or more packets contain the {term}`cryptographic signature` corresponding to the original data.
 
 2. [**Literal data packet**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit): This contains the original data (e.g., the body of a message), without additional interpretation or conversion.
 
-Note that the signature packet(s) is/are stored ahead of the message itself, in this format. For verification, this is equally convenient as the one-pass signed message form. However, to create this form, the data must be processed twice: one time reading it to calculate the cryptographic signature, and one time to copy the data into the OpenPGP message after the signature packet(s).
+Compared to a {term}`one-pass signed message`, there are no {term}`one-pass signature packets<One-pass Signature Packet>` in this format, and the (otherwise equivalent) {term}`signature packet(s)<signature packet>` are stored ahead of the signed data.
+
+For verification, this is equally convenient as the one-pass signed message form.
+
+However, when a signer creates a {term}`prefixed signed message`, the signed data must be processed twice:
+
+- once reading it to calculate the cryptographic signature, and
+- once more to store the data in the generated OpenPGP message, after the signature packet(s).
 
 (cleartext-signature)=
 ## Cleartext signatures