Permalink
Browse files

Merge pull request #32 from willchan/MaxNumConcurrentStreams

MaxNumConcurrentStreams: Update proposed clarification text in all documents. Fixes #19.
  • Loading branch information...
2 parents 3018b81 + 2fc3db0 commit c2c03cc245abc5b95f4a41f2efb78bd375937f91 @mnot mnot committed Feb 19, 2013
Showing with 33 additions and 16 deletions.
  1. +32 −15 draft-ietf-httpbis-http2.html
  2. +1 −1 draft-ietf-httpbis-http2.xml
@@ -396,7 +396,7 @@
content: "Internet-Draft";
}
@top-right {
- content: "January 2013";
+ content: "February 2013";
}
@top-center {
content: "HTTP/2.0";
@@ -405,7 +405,7 @@
content: "Belshe, et al.";
}
@bottom-center {
- content: "Expires August 4, 2013";
+ content: "Expires August 21, 2013";
}
@bottom-right {
content: "[Page " counter(page) "]";
@@ -438,15 +438,15 @@
<link rel="Chapter" title="9 Acknowledgements" href="#rfc.section.9">
<link rel="Chapter" href="#rfc.section.10" title="10 Normative References">
<link rel="Appendix" title="A Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.A">
- <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.588, 2012-08-25 12:28:24, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+ <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.589, 2012-11-30 14:23:31, XSLT vendor: SAXON 8.9.0.4 from Saxonica http://www.saxonica.com/">
<meta name="keywords" content="HTTP">
<link rel="schema.dct" href="http://purl.org/dc/terms/">
<meta name="dct.creator" content="Belshe, M.">
<meta name="dct.creator" content="Peon, R.">
<meta name="dct.creator" content="Thomson, M.">
<meta name="dct.creator" content="Melnikov, A.">
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-http2-latest">
- <meta name="dct.issued" scheme="ISO8601" content="2013-01-31">
+ <meta name="dct.issued" scheme="ISO8601" content="2013-02-17">
<meta name="dct.abstract" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicited push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
<meta name="description" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicited push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
</head>
@@ -466,7 +466,7 @@
<td class="right">R. Peon</td>
</tr>
<tr>
- <td class="left">Expires: August 4, 2013</td>
+ <td class="left">Expires: August 21, 2013</td>
<td class="right">Google, Inc</td>
</tr>
<tr>
@@ -487,7 +487,7 @@
</tr>
<tr>
<td class="left"></td>
- <td class="right">January 31, 2013</td>
+ <td class="right">February 17, 2013</td>
</tr>
</tbody>
</table>
@@ -520,7 +520,7 @@ <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC E
documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
in progress”.
</p>
- <p>This Internet-Draft will expire on August 4, 2013.</p>
+ <p>This Internet-Draft will expire on August 21, 2013.</p>
<h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
@@ -629,6 +629,7 @@ <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.2">HTTP Headers and HTTP/2.0 Headers</a></li>
<li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.3">Cross-Protocol Attacks</a></li>
<li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.4">Server Push Implicit Headers</a></li>
+ <li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.6.5">Cacheability of Pushed Resources</a></li>
</ul>
</li>
<li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7">Privacy Considerations</a><ul>
@@ -708,12 +709,13 @@ <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="versioni
<p id="rfc.section.2.1.p.5">Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial convenience only. Implementations
of draft versions MUST NOT identify using this string.
</p>
- <p id="rfc.section.2.1.p.6">Implementations of draft versions of the protocol MUST add the corresponding draft number to the identifier before the separator
- ('/'). For example, draft-ietf-httpbis-http2-03 is identified using the string "HTTP-03/2.0".
+ <p id="rfc.section.2.1.p.6">Implementations of draft versions of the protocol MUST add the string "-draft-" and the corresponding draft number to the
+ identifier before the separator ('/'). For example, draft-ietf-httpbis-http2-03 is identified using the string "HTTP-draft-03/2.0".
</p>
- <p id="rfc.section.2.1.p.7">Non-compatible experiments that are based on these draft versions MUST include a further identifier. For example, an experimental
- implementation of packet mood-based encoding based on draft-ietf-httpbis-http2-07 might identify itself as "HTTP-07-emo/2.0".
- Note that any label MUST conform with the "token" syntax defined in Section 3.2.4 of <a href="#HTTP-p1" id="rfc.xref.HTTP-p1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[HTTP-p1]</cite></a>. Experimenters are encouraged to coordinate their experiments on the ietf-http-wg@w3.org mailing list.
+ <p id="rfc.section.2.1.p.7">Non-compatible experiments that are based on these draft versions MUST instead replace the string "draft" with a different
+ identifier. For example, an experimental implementation of packet mood-based encoding based on draft-ietf-httpbis-http2-07
+ might identify itself as "HTTP-emo-07/2.0". Note that any label MUST conform with the "token" syntax defined in Section 3.2.4
+ of <a href="#HTTP-p1" id="rfc.xref.HTTP-p1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[HTTP-p1]</cite></a>. Experimenters are encouraged to coordinate their experiments on the ietf-http-wg@w3.org mailing list.
</p>
<h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="discover-http" href="#discover-http">Starting HTTP/2.0 for "http:" URIs</a></h2>
<p id="rfc.section.2.2.p.1">A client that makes a request to an "http:" URI without prior knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism <a href="#HTTP-p2" id="rfc.xref.HTTP-p2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[HTTP-p2]</cite></a>. The client makes an HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2.0.
@@ -1173,8 +1175,9 @@ <h3 id="rfc.section.3.6.4"><a href="#rfc.section.3.6.4">3.6.4</a>&nbsp;<a id="SE
defined as the minimum amount of time to send a control frame from this client to the remote and receive a response. The value
is represented in milliseconds.
</li>
- <li>4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent streams
- which it will allow. By default there is no limit. For implementors it is recommended that this value be no smaller than 100.
+ <li>4 - SETTINGS_MAX_CONCURRENT_STREAMS indicates the maximum number of concurrent streams which the sender of the SETTINGS frame
+ is willing to allow the peer to open. Note that this limit is directional. By default there is no limit. For implementors
+ it is recommended that this value be no smaller than 100, so as not to unnecessarily limit parallelism.
</li>
<li>5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value.</li>
<li>6 - SETTINGS_DOWNLOAD_RETRANS_RATE allows the sender to inform the remote endpoint the retransmission rate (bytes retransmitted
@@ -1997,6 +2000,17 @@ <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;Server Push Imp
header) to work, however, all cached resources must have a set of request headers. For this reason, browsers MUST be careful
to inherit request headers from the associated stream for the push. This includes the 'Cookie' header.
</p>
+ <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;Cacheability of Pushed Resources
+ </h2>
+ <p id="rfc.section.6.5.p.1">Caching resources that are pushed is possible, based on the guidance provided by the origin server in the Cache-Control header
+ field. However, this can cause issues if a single server hosts more than one tenant. For example, a server might offer multiple
+ users each a small portion of its URI space.
+ </p>
+ <p id="rfc.section.6.5.p.2">Where multiple tenants share space on the same server, that server MUST ensure that tenants are not able to push representations
+ of resources that they do not have authority over. Failure to enforce this would allow a tenant to provide a representation
+ that would be served out of cache, overriding the actual representation that the authoritative tenant provides.
+ </p>
+ <p id="rfc.section.6.5.p.3">Pushed resources for which an origin server is not authoritative are never cached or used.</p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;Privacy Considerations
</h1>
<h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;Long Lived Connections
@@ -2120,7 +2134,10 @@ <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
</div>
<h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
<h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.since.draft-ietf-httpbis-http2-01" href="#changes.since.draft-ietf-httpbis-http2-01">Since draft-ietf-httpbis-http2-01</a></h2>
- <p id="rfc.section.A.1.p.1">None yet</p>
+ <p id="rfc.section.A.1.p.1">Removed per-frame version field.</p>
+ <p id="rfc.section.A.1.p.2">Altered flow control properties to include session-level limits.</p>
+ <p id="rfc.section.A.1.p.3">Added note on cacheability of pushed resources and multiple tenant servers.</p>
+ <p id="rfc.section.A.1.p.4">Changed protocol label form based on discussions.</p>
<h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.since.draft-ietf-httpbis-http2-00" href="#changes.since.draft-ietf-httpbis-http2-00">Since draft-ietf-httpbis-http2-00</a></h2>
<p id="rfc.section.A.2.p.1">Changed title throughout.</p>
<p id="rfc.section.A.2.p.2">Removed section on Incompatibilities with SPDY draft#2.</p>
@@ -690,7 +690,7 @@ For example:
<t>1 - SETTINGS_UPLOAD_BANDWIDTH allows the sender to send its expected upload bandwidth on this channel. This number is an estimate. The value should be the integral number of kilobytes per second that the sender predicts as an expected maximum upload channel capacity.</t>
<t>2 - SETTINGS_DOWNLOAD_BANDWIDTH allows the sender to send its expected download bandwidth on this channel. This number is an estimate. The value should be the integral number of kilobytes per second that the sender predicts as an expected maximum download channel capacity.</t>
<t>3 - SETTINGS_ROUND_TRIP_TIME allows the sender to send its expected round-trip-time on this channel. The round trip time is defined as the minimum amount of time to send a control frame from this client to the remote and receive a response. The value is represented in milliseconds.</t>
-<t>4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent streams which it will allow. By default there is no limit. For implementors it is recommended that this value be no smaller than 100.</t>
+<t>4 - SETTINGS_MAX_CONCURRENT_STREAMS indicates the maximum number of concurrent streams which the sender of the SETTINGS frame is willing to allow the peer to open. Note that this limit is directional. By default there is no limit. For implementors it is recommended that this value be no smaller than 100, so as not to unnecessarily limit parallelism.</t>
<t>5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value.</t>
<t>6 - SETTINGS_DOWNLOAD_RETRANS_RATE allows the sender to inform the remote endpoint the retransmission rate (bytes retransmitted / total bytes transmitted).</t>
<t>7 - SETTINGS_INITIAL_WINDOW_SIZE allows the sender to inform the remote endpoint the initial window size (in bytes) for new streams.</t>

0 comments on commit c2c03cc

Please sign in to comment.