ibr2: Simplify the stream features listing

inbox/ibr2.xml

@@ -31,6 +31,17 @@
   <supersededby/>
   <shortname>ibr2</shortname>
   &sam;
+  <revision>
+    <version>0.0.2</version>
+    <date>2017-02-15</date>
+    <initials>ssw</initials>
+    <remark>
+      <ul>
+        <li>Don't allow feature to act as auth.</li>
+        <li>Use a more conventional list for challenge type listings.</li>
+      </ul>
+    </remark>
+  </revision>
   <revision>
     <version>0.0.1</version>
     <date>2017-02-08</date>
@@ -135,58 +146,24 @@
     'urn:xmpp:register:0' namespace for account registration, or a
     &lt;recovery/&gt; element qualified by the same namespace for account
     recovery.
-    This SHOULD be done when informing a client that authentication is
+    The register and recovery features are always voluntary-to-negotiate.
-    required.
+    The registration and recovery features MUST NOT be advertised before
-    These features MUST NOT be advertised before encryption has been
+    encryption has been negotiated, eg. using direct-TLS or STARTTLS.
-    negotiated, eg. using direct-TLS or STARTTLS.
+    They SHOULD be advertised at the same time as the SASL authentication
-  </p>
+    feature, meaning that after registration or recovery is completed SASL
-  <p>
+    authentication can proceed.
-    If the registration challenges contain enough data to consider the
-    connection authenticated after negotiation is successful or authentication
-    is not required by the server (eg. the server only allows temporary
-    registrations using this protocol), the register feature MUST be
-    advertised as mandatory-to-negotiate (indicating that the client may pick
-    between registration and authentication, if advertised).
-    This is accomplished by including an empty &lt;required/&gt; child element
-    in the feature.
-  </p>
-  <p>
-    If SASL authentication should be performed after registration,
-    registration should be voluntary-to-negotiate (no &lt;required/&gt; child
-    element) and thus may be negotiated before SASL authentication (which is
-    always mandatory-to-negotiate).
-  </p>
-  <p>
-    If authentication is not advertised, recovery MUST NOT be advertised.
-  </p>
-  <p>
-    If account recovery would result in the user being authenticated (eg. the
-    recovery process involved proving the users identity, and entering a new
-    password) recovery MUST be advertised as mandatory-to-negotiate indicating
-    that it may be selected instead of authentication.
-    This is accomplished by including an empty &lt;required/&gt; child element
-    in the feature.
-  </p>
-  <p>
-    If account recovery does not provide enough information to authenticate
-    the user (eg. the user was sent an email and opened a link to a web form
-    where they could reset their password, but the password is not entered
-    into the client) then it MUST be advertised as voluntary-to-negotiate (no
-    &lt;required/&gt; child element).
-    This indicates that authentication or another mandatory to negotiate
-    feature MUST be selected after the recovery process is complete.
   </p>
   <p>
     For recovery or registration, the server MUST include a list of all
-    challenges which the client may receive during the course of registering
+    challenge types which the client may receive during the course of
-    or recovering an account.
+    registering or recovering an account.
     The purpose of this list is to allow clients to detect if registration
     requires a challenge type which the client does not support, so servers
-    need only include each type once; the list is merely informative, and
+    SHOULD only include each type once; the list is merely informative, and
     should not be relied upon by clients except to ensure that all mechanisms
     are supported.
-    This list should comprise &lt;challenge/&gt; elements with a 'type'
+    This list should comprise &lt;challenge/&gt; elements containing a string
-    attribute that uniquely identifies the type of challenge being issued.
+    that uniquely identifies the type of challenge being issued.
   </p>
   <example caption="Host Advertises Stream Features"><![CDATA[
 <stream:features>
@@ -197,12 +174,11 @@
     <mechanism>PLAIN</mechanism>
   </mechanisms>
   <register xmlns='urn:xmpp:register:0'>
-    <required/>
+    <challenge>jabber:x:data'</challenge>
-    <challenge type='jabber:x:data'/>
+    <challenge>pow-example</challenge>
-    <challenge type='pow-example'/>
   </register>
   <recovery xmlns='urn:xmpp:register:0'>
-    <challenge type='jabber:x:oob'/>
+    <challenge>jabber:x:oob</challenge>
   </recovery>
 </stream:features>]]></example>
 </section1>