diff --git a/inbox/hacx.xml b/inbox/hacx.xml
index f4c737ae..788d7f44 100644
--- a/inbox/hacx.xml
+++ b/inbox/hacx.xml
@@ -38,14 +38,26 @@
   <p>Various methods exist to connect to XMPP servers over direct TLS, &xep0368; defines SRV records, &rfc7395; defines websocket, &xep0206; defines BOSH. HACX defines a method to retrieve all of those along with optional extra information such as SNI/ALPN requirements and pinned public keys from a &rfc5785; well-known URI over HTTPS.</p>
 </section1>
 <section1 topic='Requirements' anchor='reqs'>
+  <ul>
+    <li>Needs to look like HTTPS.</li>
+    <li>Needs to support all current and future XMPP connection methods through extensibility</li>
+    <li>Should be as simple as possible, all XMPP clients already have an XML parser, most have an HTTP client</li>
+  </ul>
+  <p>Several alternatives were considered to avoid writing yet-another-spec but they were all deficient in various ways:</p>
+  <ul>
+      <li>DOH (DNS-over-HTTPS) or DNS-over-TLS could be used to look up &xep0368; SRV records, but can't mix priority/weight with &xep0156; alternative methods, and can't support extra features such as domain fronting (arbitrary SNI/ALPN)</li>
+      <li>&xep0156; has a similar HTTP .well-known URL document, but since the XSF doesn't control the namespace we can't extend it with the extra required attributes to support weight/priority/alpn/sni and pinned keys, along with future methods.  The business rules also state that it must only be used as a fallback which is in direct opposition of what HACX requires.</li>
+      <li>&posh; pins certificates instead of keys, and also explicitly allows other forms of authentication (like a cert issued by a trusted CA), which is incompatible with a network attacker that might control a CA</li>
+  </ul>
+</section1>
+<section1 topic='Protocol' anchor='proto'>
     <p>HACX servers MUST use HTTPS.  This means that
    the HACX client MUST verify the certificate of the HTTPS service at
    the source domain in order to securely "bootstrap" into the use of
    HACX; specifically, the rules of &rfc2818; apply to this
    "bootstrapping" step to provide a secure basis for all subsequent
-   HACX operations.  HACX clients and servers MUST support and use
-   methods to increase the security of this HTTPS request using all available
-   means such as HPKP (&rfc7469;), HSTS (&rfc6797;), DANE (&rfc6698;), etc.
+   HACX operations.  HACX clients and servers MUST support HPKP (&rfc7469;), HSTS (&rfc6797;), and DANE (&rfc6698;),
+   and SHOULD support any future standard that serves to increase the security of this HTTPS request.
     </p>
     <p>A HACX document is retrieved over secure HTTP in the
    following way:</p>