From dc89a3121129fa642e46aef61b57bc5f7ce987a8 Mon Sep 17 00:00:00 2001
From: Sam Whited <sam@samwhited.com>
Date: Wed, 22 Apr 2020 10:13:29 -0400
Subject: [PATCH] XEP-0389: fix various typos and misspellings

---
 xep-0389.xml | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xep-0389.xml b/xep-0389.xml
index 2bb7d96d..f541d0b3 100644
--- a/xep-0389.xml
+++ b/xep-0389.xml
@@ -87,7 +87,7 @@
     To solve these issues this specification provides a new in-band registration
     protocol that allows servers to present the user with a series of
     "challenges".
-    This allows for both multi-stage proof-of-posession registration flows and
+    This allows for both multi-stage proof-of-possession registration flows and
     spam prevention mechanisms such as proof-of-work functions.
   </p>
 </section1>
@@ -140,7 +140,7 @@
       continue.
     </li>
     <li>
-      As a server operator I want to prevent SPIM using a proof-of-posession
+      As a server operator I want to prevent SPIM using a proof-of-possession
       protocol so I present the user with a form asking for a mobile phone
       number and then send a verification code to that number via SMS and show
       another form requesting the verification code.
@@ -302,7 +302,7 @@
   <p>
     After a challenge is received, the client replies to the challenge by
     sending a &lt;response/&gt; element qualified by the 'urn:xmpp:register:0'
-    namespace or a cancelation as defined later in this document.
+    namespace or a cancellation as defined later in this document.
     If the client sends a response, it MUST also include a payload defined by
     the specific challenge type.
     In the case of a jabber:x:data challenge, the payload should be a form
@@ -348,8 +348,8 @@
     wishes to cancel the flow, it MAY respond to any IQ from the client with the
     cancel element and type "result".
   </p>
-  <example caption='Server cancels rquest'><![CDATA[
-<iq type="result" id="bar">
+  <example caption='Server cancels request'><![CDATA[
+<iq type='result' id='bar'>
   <cancel xmlns='urn:xmpp:register:0'/>
 </iq>]]></example>
   <p>
@@ -367,8 +367,8 @@
     If the IQ based flow is being used and the server wishes to indicate success
     it sends an empty IQ response of type "result".
   </p>
-  <example caption='Server indicates success after stream negotation'><![CDATA[
-<iq type="result" id="bar" />]]></example>
+  <example caption='Server indicates success after stream negotiation'><![CDATA[
+<iq type='result' id='bar' />]]></example>
 </section1>
 <section1 topic='Internationalization Considerations' anchor='i18n'>
   <p>
@@ -387,7 +387,7 @@
     Servers that allow in-band registration need to take measures to prevent
     abuse.
     Common techniques to prevent spam registrations include displaying CAPTCHAs
-    or requiring proof-of-posession of a valid email address or telephone number
+    or requiring proof-of-possession of a valid email address or telephone number
     by sending a unique code (e.g. an HMAC that can later be verified as having
     originated at the server) to the users email and requiring that they enter
     the code before continuing.