UPGRADE: Resolve issues, spin off a CR for a CfC.

Author: mikewest

specs/Makefile

@@ -23,7 +23,7 @@ POWER: powerfulfeatures/index.html
 POWER-WD: powerfulfeatures/published/WD.html
 REFERRER: referrer-policy/index.html
 UPGRADE: upgrade/index.html
-UPGRADE-WD: upgrade/published/WD.html
+UPGRADE-CR: upgrade/published/2015-09-CR.html
 
 clear-site-data/index.html: clear-site-data/index.src.html biblio.json
 	bikeshed -f spec ./clear-site-data/index.src.html
@@ -79,5 +79,8 @@ upgrade/index.html: upgrade/index.src.html biblio.json
 upgrade/published/WD.html: upgrade/index.src.html
 	bikeshed -f spec --md-status=WD ./upgrade/index.src.html ./upgrade/published/WD.html
 
+upgrade/published/2015-09-CR.html: upgrade/index.src.html
+	bikeshed -f spec --md-status=CR --md-date=2015-09-01 --md-deadline=2015-11-01 ./upgrade/index.src.html ./upgrade/published/2015-09-CR.html
+
 publish:
 	git push origin master master:gh-pages

specs/upgrade/index.html

@@ -71,7 +71,7 @@
    <h1 class="p-name no-ref" id="title">Upgrade Insecure Requests</h1>
 
    <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft,
-    <time class="dt-updated" datetime="2015-08-10">10 August 2015</time></span></h2>
+    <time class="dt-updated" datetime="2015-08-12">12 August 2015</time></span></h2>
 
    <div data-fill-with="spec-metadata">
     <dl>
@@ -85,7 +85,6 @@ <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="cont
      <dd><span><a href="mailto:[email protected]?subject=%5Bupgrade-insecure-requests%5D%20YOUR%20TOPIC%20HERE">[email protected]</a> with subject line “<kbd>[upgrade-insecure-requests] <var>… message topic …</var></kbd>” (<a href="http://lists.w3.org/Archives/Public/public-webappsec/" rel="discussion">archives</a>)</span>
      <dt>Issue Tracking:
      <dd><a href="https://github.com/w3c/webappsec/issues/">GitHub</a>
-     <dd><a href="#issues-index">Inline In Spec</a>
      <dt class="editor">Editor:
      <dd class="editor p-author h-card vcard" data-editor-id="56384"><a class="p-name fn u-email email" href="mailto:[email protected]">Mike West</a> (<span class="p-org org">Google Inc.</span>)
     </dl>
@@ -237,7 +236,6 @@ <h2 class="no-num no-toc no-ref heading settled" id="contents"><span class="cont
       <li><a href="#normative"><span class="secno"></span> <span class="content">Normative References</span></a>
       <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
      </ul>
-    <li><a href="#issues-index"><span class="secno"></span> <span class="content">Issues Index</span></a>
    </ul></div>
 
   <main>
@@ -838,15 +836,6 @@ <h3 class="heading settled" data-level="3.1" id="delivery"><span class="secno">3
   default-src https:; report-uri /endpoint</code>. See <a href="#reporting-upgrades">§3.4 Reporting Upgrades</a>
   for additional detail.</p>
 
-
-    <p class="issue" id="issue-c64cf7d1"><a class="self-link" href="#issue-c64cf7d1"></a> In
-  <a href="https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0042.html">a thread on public-webappsec@</a>,
-  Peter Eckersley suggested modifying this to allow whitelisting specific hosts,
-  rather than upgrading everything: "That way, if you have N third parties
-  on a site, and (say) two of them provide images only, and don’t support
-  HTTPS at all, you can use the upgrade mechanism for scripts on the other
-  N - 2 origins." <a href="https://github.com/w3c/webappsec/issues/184">&lt;https://github.com/w3c/webappsec/issues/184></a></p>
-
 
     <h4 class="heading settled" data-level="3.1.1" id="mix"><span class="secno">3.1.1. </span><span class="content">Relation to "Mixed Content"</span><a class="self-link" href="#mix"></a></h4>
 
@@ -892,7 +881,8 @@ <h4 class="heading settled" data-level="3.2.1" id="preference"><span class="secn
   </span><a class="self-link" href="#preference"></a></h4>
 
 
-    <p>The <dfn data-dfn-type="dfn" data-export="" data-local-lt="Upgrade-Insecure-Requests header field" id="upgrade_insecure_requests-http-request-header-field">
+    <p>The <dfn data-dfn-type="dfn" data-export="" data-local-lt="Upgrade-Insecure-Requests header field" data-lt="Upgrade-Insecure-Requests HTTP request header
+  field" id="upgrade_insecure_requests-http-request-header-field">
   <code>Upgrade-Insecure-Requests</code> HTTP request header
   field<a class="self-link" href="#upgrade_insecure_requests-http-request-header-field"></a></dfn> sends a signal to the server expressing the client’s preference
   for an encrypted and authenticated response, and that it can successfully
@@ -1156,18 +1146,14 @@ <h3 class="heading settled" data-level="3.3" id="nesting"><span class="secno">3.
 
       </ol>
 
-
-
-      <p class="issue" id="issue-61dd79e9"><a class="self-link" href="#issue-61dd79e9"></a> Monkey patching. :(</p>
-      
 
 
 
     </ol>
 
 
-    <p class="issue" id="issue-9721e5e6"><a class="self-link" href="#issue-9721e5e6"></a> The WHATWG HTML spec is significantly clearer here than <a data-link-type="biblio" href="#biblio-workers">[WORKERS]</a>.
-  Hope that doesn’t cause problems when transitioning to CR.</p>
+    <p class="note" role="note">Note: We’re using the WHATWG HTML spec’s definition of Worker algorithms, as
+  they’re significantly more clear on these points than <a data-link-type="biblio" href="#biblio-workers">[WORKERS]</a>.</p>
 
 
     <h3 class="heading settled" data-level="3.4" id="reporting-upgrades"><span class="secno">3.4. </span><span class="content">Reporting Upgrades</span><a class="self-link" href="#reporting-upgrades"></a></h3>
@@ -1915,17 +1901,5 @@ <h3 class="no-num heading settled" id="informative"><span class="content">Inform
    <dt id="biblio-nyt-https"><a class="self-link" href="#biblio-nyt-https"></a>[NYT-HTTPS]
    <dd>Eitan Konigsburg; Rajiv Pant; Elena Kvochko. <a href="http://open.blogs.nytimes.com/2014/11/1%33/embracing-https/">Embracing HTTPS</a>. URL: <a href="http://open.blogs.nytimes.com/2014/11/1%33/embracing-https/">http://open.blogs.nytimes.com/2014/11/1%33/embracing-https/</a>
    <dt id="biblio-web-https"><a class="self-link" href="#biblio-web-https"></a>[WEB-HTTPS]
-   <dd>Mark Nottingham. <a href="http://www.w3.org/2001/tag/doc/web-https">Securing the Web</a>. TAG Finding. URL: <a href="http://www.w3.org/2001/tag/doc/web-https">http://www.w3.org/2001/tag/doc/web-https</a></dl>
-  <h2 class="no-num heading settled" id="issues-index"><span class="content">Issues Index</span><a class="self-link" href="#issues-index"></a></h2>
-  <div style="counter-reset:issue">
-   <div class="issue"> In
-  <a href="https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0042.html">a thread on public-webappsec@</a>,
-  Peter Eckersley suggested modifying this to allow whitelisting specific hosts,
-  rather than upgrading everything: "That way, if you have N third parties
-  on a site, and (say) two of them provide images only, and don’t support
-  HTTPS at all, you can use the upgrade mechanism for scripts on the other
-  N - 2 origins." <a href="https://github.com/w3c/webappsec/issues/184">&lt;https://github.com/w3c/webappsec/issues/184></a><a href="#issue-c64cf7d1"> ↵ </a></div>
-   <div class="issue"> Monkey patching. :(<a href="#issue-61dd79e9"> ↵ </a></div>
-   <div class="issue"> The WHATWG HTML spec is significantly clearer here than <a data-link-type="biblio" href="#biblio-workers">[WORKERS]</a>.
-  Hope that doesn’t cause problems when transitioning to CR.<a href="#issue-9721e5e6"> ↵ </a></div></div></body>
+   <dd>Mark Nottingham. <a href="http://www.w3.org/2001/tag/doc/web-https">Securing the Web</a>. TAG Finding. URL: <a href="http://www.w3.org/2001/tag/doc/web-https">http://www.w3.org/2001/tag/doc/web-https</a></dl></body>
 </html>

specs/upgrade/index.src.html

@@ -594,14 +594,6 @@ <h3 id="delivery">
   default-src https:; report-uri /endpoint</code>. See [[#reporting-upgrades]]
   for additional detail.
 
-  ISSUE(w3c/webappsec#184): In
-  <a href="https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0042.html">a thread on public-webappsec@</a>,
-  Peter Eckersley suggested modifying this to allow whitelisting specific hosts,
-  rather than upgrading everything: "That way, if you have N third parties
-  on a site, and (say) two of them provide images only, and don't support
-  HTTPS at all, you can use the upgrade mechanism for scripts on the other
-  N - 2 origins."
-
   <h4 id="mix">Relation to "Mixed Content"</h4>
 
   The <code><a>upgrade-insecure-requests</a></code> directive results in
@@ -825,14 +817,12 @@ <h3 id="nesting">Policy Inheritance</h3>
           </ol>
         </li>
       </ol>
-
-      ISSUE: Monkey patching. :(
     </li>
   </ol>
 
-  ISSUE: The WHATWG HTML spec is significantly clearer here than [[WORKERS]].
-  Hope that doesn't cause problems when transitioning to CR.
- 
+  Note: We're using the WHATWG HTML spec's definition of Worker algorithms, as
+  they're significantly more clear on these points than [[WORKERS]].
+
   <h3 id="reporting-upgrades">Reporting Upgrades</h3>
 
   Upgrading insecure requests MUST not interfere with an authors' ability to