diff --git a/xep-0077.xml b/xep-0077.xml
index da2823a05..d60e35e8b 100644
--- a/xep-0077.xml
+++ b/xep-0077.xml
@@ -13,6 +13,7 @@
   <status>Final</status>
   <type>Standards Track</type>
   <sig>Standards</sig>
+  <approver>Council</approver>
   <dependencies>
     <spec>XMPP Core</spec>
   </dependencies>
@@ -23,6 +24,12 @@
     <url>http://www.xmpp.org/schemas/iq-register.xsd</url>
   </schemaloc>
   &stpeter;
+  <revision>
+    <version>2.5</version>
+    <date>2023-11-25</date>
+    <initials>melvo</initials>
+    <remark><p>Specify account creation via HTTP as non-exclusive alternative to XMPP</p></remark>
+  </revision>
   <revision>
     <version>2.4</version>
     <date>2012-01-25</date>
@@ -517,9 +524,12 @@
   </ol>
   <p>Support for extensibility via <cite>Data Forms</cite> is RECOMMENDED but is not required for compliance with this document.</p>
 </section1>
-<section1 topic='Redirection' anchor='redirect'>
-  <p>A given deployment MAY wish to redirect users to another medium (e.g., a website) for registration, rather than allowing in-band registration. The recommended approach is to include only the &lt;instructions/&gt; element rather than the required fields or a data form in the IQ result, as well as a URL encoded using &xep0066; (see the <link url="#precedence">Precedence Order</link> section below for further details).</p>
-  <example caption='Host Redirects Entity to Web Registration'><![CDATA[
+<section1 topic='Alternative Registration Medium' anchor='alternative-registration-medium'>
+  <p>A given deployment MAY wish to provide an alternative medium (e.g., a website) for registration.</p>
+  <section2 topic='Web Registration' anchor='web-registration'>
+    <p>Account creation via HTTP enables clients that do not support account creation via XMPP but are able to query the web registration URL to provide that URL to its users. Furthermore, providing a web registration URL in addition to support for account creation via XMPP leaves the decision which way to use for registration to the client or even to the user. That approach does not limit future development as the former one did which recommended to provide either account creation via XMPP or a web registration URL. It also allows clients that are only used for aggregating data about servers to check whether a server supports account creation via XMPP while retrieve its web registration URL.</p>
+    <p>In addition to or instead of the required fields or a data form in the IQ result, an &lt;instructions/&gt; element as well as a URL encoded using &xep0066; MAY be included (see the <link url="#precedence">Precedence Order</link> section below for further details).</p>
+    <example caption='Host Redirects Entity to Web Registration'><![CDATA[
 <iq type='result'
     from='contests.shakespeare.lit'
     to='juliet@capulet.com/balcony'
@@ -534,6 +544,7 @@
   </query>
 </iq>
 ]]></example>
+  </section2>
 </section1>
 <section1 topic='Precedence Order' anchor='precedence'>
   <p>Given the foregoing discussion, it is evident that an entity could receive any combination of iq:register, x:data, and x:oob namespaces from a service in response to a request for information. The precedence order is as follows:</p>
@@ -583,7 +594,7 @@
     <tr>
       <td>iq:register fields + x:oob URL</td>
       <td>Submit the completed iq:register fields but optionally present the provided URL as an alternative.</td>
-      <td>This combination is NOT RECOMMENDED.</td>
+      <td>This combination MAY be returned if the server provides both registrations via XMPP and HTTP.</td>
     </tr>
   </table>
 </section1>