diff --git a/xep-0389.xml b/xep-0389.xml
index a95c8ffa..6f9d81b0 100644
--- a/xep-0389.xml
+++ b/xep-0389.xml
@@ -31,6 +31,14 @@
   <supersededby/>
   <shortname>ibr2</shortname>
   &sam;
+  <revision>
+    <version>0.6.0</version>
+    <date>2020-11-17</date>
+    <initials>ssw</initials>
+    <remark>
+      <p>Error out if a client selects an invalid flow</p>
+    </remark>
+  </revision>
   <revision>
     <version>0.5.0</version>
     <date>2020-05-26</date>
@@ -363,7 +371,7 @@
       If an entity supports issuing challenges but does not provide any flows
       after stream negotiation is complete it MUST respond with an empty list.
       Similarly, an entity that supports this specification but does not support
-      issuign challenges itself (for example, a client that only supports
+      issuing challenges itself (for example, a client that only supports
       receiving challenges) it MUST respond successfully with an empty list.
     </p>
     <example caption='Empty registration flows results'><![CDATA[
@@ -371,7 +379,7 @@
   <register xmlns='urn:xmpp:register:0'/>
 </iq>]]></example>
   </section2>
-  <section2 topic='Issuing Challenges' anchor='challenge'>
+  <section2 topic='Selecting a Flow' anchor='selecting'>
     <p>
       A client selects the registration or recovery feature for negotiation by
       replying with an element of the same name and namespace.
@@ -384,6 +392,19 @@
 <register xmlns='urn:xmpp:register:0'>
   <flow id='1'/>
 </register>]]></example>
+    <p>
+      If during stream initialization the client attempts to select a flow that
+      does not match one of the flows sent by the server, the server MUST
+      respond with an "undefined-condition" stream error containing an
+      "invalid-flow" application error qualified by the 'urn:xmpp:register:0'
+      namespace.
+    </p>
+    <example caption='Server responds to an invalid selection during stream negotiation'><![CDATA[
+<stream:error>
+  <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
+  <invalid-flow xmlns='urn:xmpp:register:0'/>
+</stream:error>
+</stream:stream>]]></example>
     <p>
       If the client is initiating registration or recovery after a stream has
       already been initiated it uses the same registration element wrapped in an
@@ -396,7 +417,21 @@
   </recovery>
 </iq>]]></example>
     <p>
-      The server then replies to the IQ or feature selection with a challenge.
+      If the client attempts to select a flow that does not match one of the
+      flows sent by the server in response to an IQ after stream initialization
+      the server MUST respond with a stanza error of type "item-not-found".
+    </p>
+    <example caption='Server responds to an invalid selection after stream negotiation'><![CDATA[
+<iq type='error'>
+  <error type='cancel'>
+    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
+  </error>
+</iq>]]></example>
+  </section2>
+  <section2 topic='Issuing Challenges' anchor='challenge'>
+    <p>
+      If a valid flow is selected by the client the server then replies to the
+      IQ or feature selection with a challenge.
       If replying to an IQ, the challenge must be wrapped in an IQ of type
       "result".
       Challenges take the form of a &lt;challenge/&gt; element qualified by the