UPGRADE: Fetch nitpicking.

specs/upgrade/index.src.html

@@ -332,7 +332,7 @@ <h2 id="upgrading">Upgrading Insecure Resource Requests</h2>
       set to <a for="insecure requests policy" value>Do Not Upgrade</a> unless
       otherwise specified. This policy is checked in [[#upgrade-request]] in
       order to determine whether or not subresource requests and form
-      submissions should be upgraded during <a>Fetching</a>.
+      submissions should be upgraded during <a>fetching</a>.
     </li>
     <li>
       <a>Environment settings objects</a> and <a>browsing contexts</a> are
@@ -592,7 +592,7 @@ <h3 id="reporting-upgrades">Reporting Upgrades</h3>
   </div>
 
   Note: This will be significantly clarified once [[CSP2]] is rewritten in terms
-  of Fetch.
+  of [[FETCH]].
 </section>
 
 <!-- Big Text: Algorithms -->
@@ -614,7 +614,8 @@ <h3 id="upgrade-request">
   form submissions. Form submissions will be upgraded to mitigate the risk of
   data leakage via plaintext submissions.
 
-  ISSUE: This should be called from Fetch, probably after the existing step #3.
+  ISSUE: This should be called from [[FETCH]], probably after the existing step
+  #3.
 
   <ol>
     <li>
@@ -689,7 +690,7 @@ <h3 id="upgrade-request">
     </li>
   </ol>
 
-  Note: Due to Fetch's recursive nature, this algorithm will upgrade
+  Note: Due to [[FETCH]]'s recursive nature, this algorithm will upgrade
   insecurely-redirected requests as well as insecure initial requests.
 
   <h3 id="should-upgrade-for-client">
@@ -738,7 +739,7 @@ <h3 id="should-upgrade-for-client">
 <section>
   <h2 id="websockets-integration">Modifications to WebSockets</h2>
 
-  WebSockets do not use the <a>Fetching</a> algorithm, so we need to handle
+  WebSockets do not use the <a>fetching</a> algorithm, so we need to handle
   those requests separately.
 
   The <a>establish a WebSocket connection</a> algorithm [[!RFC6455]] is modified