host-meta-2: Add overall reason and paramater explanation to rationale

inbox/host-meta-2.xml

@@ -206,6 +206,7 @@ Access-Control-Allow-Origin: *
 </section1>
 
 <section1 topic='Rationale' anchor='rationale'>
+  <p>At the time of this writing, connecting to an XMPP server requires at least 5 seperate fetches of data, and doesn't support half the things this XEP does.  I don't find adding more fetches a sustainable path forward, hence definining one extensible method for all things going forward.</p>
   <p>Here I will go through alternative solutions that were explored and explain their deficiencies and why they were not chosen.</p>
   <section2 topic='Why not DNS?' anchor='rationale-dns'>
       <ul>
@@ -231,6 +232,13 @@ Access-Control-Allow-Origin: *
         <li>As stated in the section above, I find a JSON parser much less of a potential security vulnerability to have available than an XML parser capable of parsing host-meta.xml</li>
       </ul>
   </section2>
+  <section2 topic='Why do we even need these additional parameters?' anchor='rationale-params'>
+      <ul>
+        <li>SNI fixes a fundamental problem we have with current methods of secure delegation (XEP-0156 and DNSSEC signed SRV records), in that these enable certificate validation to allow a certificate if it contains either one of two names, the service name *or* the target name. But you can only send one name with SNI, and nothing indicates which to send! If you send the wrong one the connection will fail, this necessitates sending one and, if it fails, sending the other, which is of course less than ideal.</li>
+        <li>ECH allows encrypting SNI+ALPN on the wire and so is invaluable for privacy.</li>
+        <li>Pinned public keys are a better replacement for POSH (they don't need changed on certificate renewal which commonly happens every 60 days now), and an alternative to DANE which can't be used where DNSSEC is not available.</li>
+      </ul>
+  </section2>
   <section2 topic='Misc' anchor='rationale-misc'>
       <ul>
         <li>host-meta.json has an 'expires' key defined already, why 'ttl' instead? I was almost convinced to use this until I realized this means that the file needs served by a program that can update 'expires' dynamically on fetch, or at least on a schedule, and that is far more complicated and therefore less preferable than a simple ttl that never needs updated allowing clients to keep track of their own expiry.</li>