diff --git a/draft-ietf-httpbis-encryption-encoding.md b/draft-ietf-httpbis-encryption-encoding.md
index 8903c87e5..eae142492 100644
--- a/draft-ietf-httpbis-encryption-encoding.md
+++ b/draft-ietf-httpbis-encryption-encoding.md
@@ -361,8 +361,10 @@ wrapping is added to fit formatting constraints.
 
 ## Encryption of a Response {#explicit}
 
-Here, a successful HTTP GET response has been encrypted using input keying
-material that is identified by the string "a1".
+Here, a successful HTTP GET response has been encrypted.  This uses a record
+size of 4096 and the minimum of 2 octets of padding, so only a partial record is
+present.  The input keying material is identified by an empty string (that is,
+the "keyid" field in the header is zero octets in length).
 
 The encrypted data in this example is the UTF-8 encoded string "I am the
 walrus".  The input keying material is included in the Crypto-Key header field.
@@ -376,20 +378,33 @@ Content-Length: 33
 Content-Encoding: aes128gcm
 Crypto-Key: aes128gcm=6Aqf1aDH8lSxLyCpoCnAqg
 
-lVIUs_H0A2a8-6dhmzY57H4K4uRFCF6tIIPRO9vrOL6B
+sJvlboCWzB5jr8hI_q9cOQAAEAAANSmxkSVa0-MiNNuF77YHSs-iwaNe_OK0qfmO
+c7NT5WSW
 ~~~
 
 Note that the media type has been changed to "application/octet-stream" to avoid
 exposing information about the content.  Alternatively (and equivalently), the
 Content-Type header field can be omitted.
 
+Intermediate values for this example (all shown in base64):
+
+~~~ inline
+salt (from header) = sJvlboCWzB5jr8hI_q9cOQ
+PRK = MLAQxt_DHjM15cdlyU1oUnjq7TFlzToGTkdRmvvxVBw
+CEK = v31u7VGV3soO3wNaMaIdhg
+NONCE = XOaygzko98zjUFTJ
+plaintext = AABJIGFtIHRoZSB3YWxydXM
+~~~
+
 
 ## Encryption with Multiple Records
 
-This example shows the same encrypted message, but split into records of 10
-octets each.  The first record includes a single additional octet of padding,
-which causes the end of the content to align with a record boundary, forcing the
-creation of a third record that contains only padding.
+This example shows the same message, but the plaintext is split into records of
+10 octets each (that is, the "rs" field in the header is 10).  The first record
+includes a single additional octet of padding.  This means that there are 7
+octets of message in the first record, and 8 in the second.  This causes the end
+of the content to align with a record boundary, forcing the creation of a third
+record that contains only two octets of padding.
 
 ~~~ example
 HTTP/1.1 200 OK
@@ -397,8 +412,8 @@ Content-Length: 70
 Content-Encoding: aes128gcm
 Crypto-Key: keyid="a1"; aes128gcm="BO3ZVPxUlnLORbVGMpbT1Q"
 
-iBmR5fjBCUvicKLSt1L1GQAAAAoCYTGZvfb0yACNxTo090xk6m_6GwMiLv4AxGSS
-_BFGyZS_2z_cOxSHLfuPsAQiId243MTE8B_5Vg-R5OPTNbiV3PlHJcjGONoI
+uNCkWiNYzKTnBN9ji3-qWAAAAAoCYTGHOqYFz-0in3dpb-VE2GfBngkaPy6bZus_
+qLF79s6zQyTSsA0iLOKyd3JqVIwprNzVatRCWZGUx_qsFbJBCQu62RqQuR2d
 ~~~
 
 
@@ -605,7 +620,7 @@ Serialization as:
 
 ~~~ example
 eyAiYWxnIjogImRpciIsICJlbmMiOiAiQTEyOEdDTSIgfQ..31iQYc1v4a36EgyJ.
-VDeU0XxaJkOJDAxPl7h9JD4.VfDeN0aKz-z36T3WWULsBQ
+NSmxkSVa0-MiNNuF77YHSs8.osGjXvzitKn5jnOzU-Vklg
 ~~~
 
 Where the first line represents the fixed JWE Protected Header, an empty JWE