MIX: Clarify mixed content "resources" vs "requests".

Jeff Hodges noted in [1] that MIX was a bit iffy from an editorial
perspective with regared to defining mixed content in terms of resources
loaded into a context, while at the same time banning certain resource
loads entirely. This patch attempts to clean things up by defining
"mixed content" in terms of both resources and requests, and adjusting
the definitions of "optionally-blockable" and "blockable" to match. Each
of these terms now covers the following:

1.  A request for an insecure resource that is blocked before the resource
    is loaded into the requesting context.

2.  A request for an insecure resource that is allowed to proceed despite
    its mixed nature.

3.  An insecure resource that is loaded into a secure context via a
    request described by #2.

Thanks, @equalsJeffH!

[1]: https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0107.html

specs/mixedcontent/index.src.html

@@ -10,7 +10,10 @@ <h1>Mixed Content</h1>
 Level: 1
 Editor: Mike West 56384, Google Inc., mkwst@google.com
 Group: webappsec
-Abstract: This specification describes how a user agent should handle fetching of content loaded over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document.
+Abstract:
+  This specification describes how a user agent should handle fetching of
+  content over unencrypted or unauthenticated connections in the context of an
+  encrypted and authenticated document.
 Version History: https://github.com/w3c/webappsec/commits/master/specs/mixedcontent/index.src.html
 Indent: 2
 At Risk: The <a>deprecated TLS-protection</a> concept.
@@ -186,15 +189,24 @@ <h2 id="terms">Key Concepts and Terminology</h2>
       <dfn export local-lt="mixed">mixed content</dfn>
     </dt>
     <dd>
-      A resource is said to be <strong>mixed content</strong> if the resource's
+      A resource or <a>request</a> is <strong>mixed content</strong> if its
       <a>origin</a> is <a>insecure</a>, <strong>and</strong> the context
       responsible for loading it restricts mixed content. See
       [[#categorize-settings-object]] for a normative definition of the latter.
 
       <div class="example">
-        The image <code>http://example.com/image.png</code> is <strong>mixed
-        content</strong> when loaded by
-        <code>https://not.example.com/</code>.
+        Inside a context that restricts mixed content
+        (<code>https://secure.example.com/</code>, for example):
+
+        * A request for the script <code>http://example.com/script.js</code> is
+          <strong>mixed content</strong>. As scripts are <a>blockable
+          content</a>, the user agent will return a network error rather than
+          loading the resource.
+
+        * A request for the image <code>http://example.com/image.png</code> is
+          <strong>mixed content</strong>. As images are <a>optionally-blockable
+          content</a>, the user agent might load the image, in which case the
+          image resource itself would be <strong>mixed content</strong>.
       </div>
     </dd>
 
@@ -215,6 +227,8 @@ <h2 id="terms">Key Concepts and Terminology</h2>
 
       A URL whose <a>origin</a> is potentially secure is itself considered to
       be potentially secure.
+
+      ISSUE: Drop <code>about</code>.
     </dd>
 
     <dt>
@@ -229,9 +243,9 @@ <h2 id="terms">Key Concepts and Terminology</h2>
     </dt>
     <dd>
       Any <a>origin</a> which is not <a>potentially secure</a> is said to
-      be <strong><i lang="la">a priori</i> insecure</strong>. We know, for example, that
-      <code>http://example.com/</code> is insecure just by looking at its scheme
-      component.
+      be <strong><i lang="la">a priori</i> insecure</strong>. We know, for
+      example, that <code>(http, example.com, 80)</code> is insecure just by
+      looking at its scheme component.
 
       A URL whose <a>origin</a> is <i lang="la">a priori</i> insecure is itself
       considered to be <i lang="la">a priori</i> insecure.
@@ -317,8 +331,7 @@ <h2 id="categories">Content Categories</h2>
   <section>
     <h3 id="category-optionally-blockable">Optionally-blockable Content</h3>
 
-    A resource is
-    <dfn local-lt="optionally-blockable">optionally-blockable content</dfn>
+    A resource or <a>request</a> is <dfn>optionally-blockable</dfn>
     when the risk of allowing its usage as <a>mixed content</a> is outweighed by
     the risk of breaking significant portions of the web. This could be because
     mixed usage of the resource type is sufficiently high, and because the
@@ -367,9 +380,8 @@ <h3 id="category-optionally-blockable">Optionally-blockable Content</h3>
   <section>
     <h3 id="category-blockable">Blockable Content</h3>
 
-    Any resource that isn't <a>optionally-blockable</a> is
-    <dfn lt="blockable content" local-lt="blockable">blockable
-    content</dfn>. Typical examples of this kind of content include scripts,
+    Any resource or <a>request</a> that isn't <a>optionally-blockable</a> is
+    <dfn>blockable</dfn>. Typical examples of this kind of content include scripts,
     <a>plugin</a> data, data requested via {{XMLHttpRequest}}, and so on. Every
     <a>request context</a> that is not <a>optionally-blockable</a> is a
     <dfn>blockable request context</dfn>. This explicitly includes any contexts