diff --git a/inbox/ecaps2.xml b/inbox/ecaps2.xml
index 92625766..40ee856a 100644
--- a/inbox/ecaps2.xml
+++ b/inbox/ecaps2.xml
@@ -729,7 +729,7 @@ cDp0aW1lHxw=</code>
     </ul>
     <section3 topic='Caching' anchor='rules-processing-caching'>
       <p>A &hash; MAY be stored alongside with its disco#info in a &hashcache;. A received &hash; which has not been verified MUST NOT be stored.</p>
-      <p>Instead of issueing a &xep0030; disco#info &lt;query/&gt; with absent 'node' attribute to a target entity, an entity MAY use a &hashcache; to obtain the response. To look up the disco#info response in the &hashcache;, an entity MUST use a hash from the &hashset; which was most recently received from the entity to which the &lt;query/&gt; would have been sent otherwise. If none of the most recently received &hashes; are found in the &hashcache;, the entity MUST fall back to sending the request.</p>
+      <p>Instead of issuing a &xep0030; disco#info &lt;query/&gt; with absent 'node' attribute to a target entity, an entity MAY use a &hashcache; to obtain the response. To look up the disco#info response in the &hashcache;, an entity MUST use a hash from the &hashset; which was most recently received from the entity to which the &lt;query/&gt; would have been sent otherwise. If none of the most recently received &hashes; are found in the &hashcache;, the entity MUST fall back to sending the request.</p>
       <p>An entity MUST NOT use &hashes; which were not included in the most recent &hashset; received from the target entity.</p>
       <p>An entity MAY use external data sources to fill the &hashcache;.</p>
     </section3>
@@ -738,7 +738,7 @@ cDp0aW1lHxw=</code>
   <section2 topic='Additional Rules for Clients and Servers implementing Caps Optimizations' anchor='rules-optimize'>
     <ul>
       <li>Servers MAY strip off the &lt;c/&gt; element if it has not changed since the previous presence broadcast.</li>
-      <li>Servers MUST ensure that the first presence notification sent to each subscriber contains the most recent &lt;c/&gt; element, if any was sent in the current presence session.</li>
+      <li>Servers MUST ensure that the first presence notification sent to each subscriber contains the most recent &lt;c/&gt; element, if any were sent in the current presence session.</li>
       <li>Servers MUST ensure that every change in the &lt;c/&gt; element is sent to all subscribers.</li>
       <li>Clients MAY omit the &lt;c/&gt; element if it has not changed since the last presence <em>iff</em> they determined that their server supports Caps Optimization.</li>
       <li>Servers MAY answer disco#info requests for &hashnodes; on behalf of their and others clients if the disco#info response belonging to that &hash; is known to them.</li>
@@ -758,7 +758,7 @@ cDp0aW1lHxw=</code>
 
 <section1 topic='Security Considerations' anchor='security'>
   <section2 topic='Hash Function Input Data Separators' anchor='security-separators'>
-    <p>The codepoints used for separating the different parts in the <link url='#algorithm-input'>Hash Function Input Algortihm</link> (&sepl4; through &sepl1;) are not allowed in well-formed XML character data. As entities are per &xmppcore; required to close a stream if non-well-formed XML data is received, these codepoints cannot occur in the input to the algorithm and their use as separators is safe.</p>
+    <p>The codepoints used for separating the different parts in the <link url='#algorithm-input'>Hash Function Input Algortihm</link> (&sepl4; through &sepl1;) are not allowed in well-formed XML character data. As entities are, per &xmppcore;, required to close a stream if non-well-formed XML data is received, these codepoints cannot occur in the input to the algorithm and their use as separators is safe.</p>
   </section2>
 
   <section2 topic='Caching' anchor='security-caching'>
@@ -768,7 +768,7 @@ cDp0aW1lHxw=</code>
   </section2>
 
   <section2 topic='Directed Presence' anchor='security-directed-presence'>
-    <p>Entities MAY choose to not send &hashsets; with directed presence for example to increase the privacy. In that case, entities SHOULD also refuse direct &xep0030; queries.</p>
+    <p>Entities MAY choose to not send &hashsets; with directed presence (for example to increase privacy). In that case, entities SHOULD also refuse direct &xep0030; queries.</p>
   </section2>
 </section1>
 
@@ -778,7 +778,7 @@ cDp0aW1lHxw=</code>
     <p>A common way to canonicalize XML which could be used is &w3canon;. It was decided not to use <cite>Canonical XML</cite> for the following reasons:</p>
     <ul>
       <li>Implementing it is quite some effort and not all XML libraries come with an implementation.</li>
-      <li>It is sensitive to the relative ordering of the elements. The relative ordering of children in disco#info &lt;query/&gt; elements does, however, not matter.</li>
+      <li>It is sensitive to the relative ordering of the elements. The relative ordering of children in disco#info &lt;query/&gt; elements, however, does not matter.</li>
       <li>Several children of &xep0128; data forms are deliberately ignored, like instructions and other descriptive text. The descriptive text is not relevant for the information is being conveyed.</li>
     </ul>
     <p>Thus, using <cite>Canonical XML</cite> would require additional, non-trivial software support and still require non-trivial additional canonicalization rules.</p>