diff --git a/xep-0379.xml b/xep-0379.xml
index 094d609e..d8440357 100644
--- a/xep-0379.xml
+++ b/xep-0379.xml
@@ -136,7 +136,7 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague
 
     </section2>
 
-    <section2 topic='Out-of-band transmission and presentation of the link' anchor='link_transmission'>
+    <section2 topic='Out-of-band Transmission and Presentation of the Link' anchor='link_transmission'>
       <p>As Romeo doesn't know Juliet's JID in advance, he needs to use an out-of-band method (like e-mail, QR codes or NFC) to transmit the invitation link to Juliet. While these methods allow transmission of <strong>xmpp:</strong> URIs, there is no mechanism to ensure that Juliet actually has a client installed that can open the URI.</p>
       <p>One way to solve this problem is to present Juliet with a web-based landing page that contains the following elements:</p>
       <ul>
@@ -189,7 +189,7 @@ https://juicyxmpp.example/i/#romeo@montague.net?preauth=1tMFqYDdKhfe2pwp;name=Ro
 
     </section2>
 
-    <section2 topic='Subcription request to the user by the link receiver (new contact)' anchor='link_transmission'>
+    <section2 topic='Subcription Request to the User by the Link Receiver (New Contact)' anchor='link_transmission'>
       <p>When Juliet opens the <strong>xmpp:</strong> URI (or the according client-supported
         landing page URI) in her client, the client should perform the usual
         roster addition action, i.e. display a dialog allowing to edit the entry
@@ -251,14 +251,14 @@ https://juicyxmpp.example/i/#romeo@montague.net?preauth=1tMFqYDdKhfe2pwp;name=Ro
     </section2>
   </section1>
   <section1 topic='Business Rules' anchor='rules'>
-    <section2 topic='Fallback to manual process' anchor='rules_fallback'>
+    <section2 topic='Fallback to Manual Process' anchor='rules_fallback'>
       <p>An implementation of this protocol MUST allow for a "graceful
         degradation" to the manual subscription approval process. If a client
         receives a malformed or unknown 'preauth' token, it MUST ignore it and act
         as if no preauth token was contained.</p>
     </section2>
 
-    <section2 topic='No expectaion of immediate approval' anchor='rules_expectation'>
+    <section2 topic='No Expectaion of Immediate Approval' anchor='rules_expectation'>
       <p>When sending a pre-authenticated subscription request, the contact's
         client MUST NOT expect an immediate successful approval. If the user's
         issuing client is currently offline, or if the token has expired, a manual
@@ -327,14 +327,14 @@ https://juicyxmpp.example/i/#romeo@montague.net?preauth=1tMFqYDdKhfe2pwp;name=Ro
     </section2>
   </section1>
   <section1 topic='Usability Considerations' anchor='usability'>
-    <section2 topic='Use of multiple clients' anchor='rules_multiclient'>
+    <section2 topic='Use of Multiple Clients' anchor='rules_multiclient'>
       <p>If a user is logged in with multiple clients, some of their clients will
         receive a subscription request with an unknown token. In this case, a client
         MAY delay the user notification for a short time, to allow another logged-in
         client to automatically handle the subscription request.</p>
     </section2>
 
-    <section2 topic='Opening the landing page in an app' anchor='rules_multiclient'>
+    <section2 topic='Opening the Landing Page in an App' anchor='rules_multiclient'>
       <p>Some mobile device platforms allow an app to register itself as a
         handler for cetain URIs. This allows an XMPP client to register for <strong>xmpp:</strong>
         URIs, but also to redirect handling of cetain HTTP/HTTPS URIs. A mobile