Merge pull request #11 from rch-chromium-org/gh-pages

Remove data compression and fix SETTINGS frame format

draft-mbelshe-spdy-00.xml

@@ -139,7 +139,6 @@
 <t>Flags: Flags related to this frame. Valid flags are:
 <list>
 <t>0x01 = FLAG_FIN - signifies that this frame represents the last frame to be transmitted on this stream.  See <xref target="StreamClose">Stream Close</xref> below.</t>
-<t>0x02 = FLAG_COMPRESS - indicates that the data in this frame has been compressed.</t>
 </list>
 </t>
 
@@ -152,8 +151,6 @@
 <t>If an endpoint receives a data frame for a stream-id which is not open and the endpoint has not sent a <xref target="GOAWAY">GOAWAY</xref> frame, it MUST send issue a <xref target="StreamErrorHandler">stream error</xref> with the error code INVALID_STREAM for the stream-id.</t>
 <t>If the endpoint which created the stream receives a data frame before receiving a SYN_REPLY on that stream, it is a protocol error, and the recipient MUST issue a <xref target="StreamErrorHandler">stream error</xref> with the status code PROTOCOL_ERROR for the stream-id.</t>
 <t>Implementors note: If an endpoint receives multiple data frames for invalid stream-ids, it MAY close the session.</t>
-<t>All SPDY endpoints MUST accept compressed data frames.  Compression of data frames is always done using zlib compression.  Each stream initializes and uses its own compression context dedicated to use within that stream.  Endpoints are encouraged to use application level compression rather than SPDY stream level compression.</t>
-<t>Each SPDY stream sending compressed frames creates its own zlib context for that stream, and these compression contexts MUST be distinct from the compression contexts used with SYN_STREAM/SYN_REPLY/HEADER compression. (Thus, if both endpoints of a stream are compressing data on the stream, there will be two zlib contexts, one for sending and one for receiving).</t>
 </list>
 </t>
         </section>
@@ -425,13 +422,21 @@
           <figure>
             <artwork>
  +----------------------------------+
- |      ID (24 bits)    | Flags (8) |
+ | Flags(8) |      ID (24 bits)     |
  +----------------------------------+
  |          Value (32 bits)         |
  +----------------------------------+
             </artwork>
           </figure>
 </t>
+
+<t>Flags: An 8 bit value.  Defined Flags:
+  <list>
+    <t>FLAG_SETTINGS_PERSIST_VALUE (0x1):   When set, the sender of this SETTINGS frame is requesting that the recipient persist the ID/Value and return it in future SETTINGS frames sent from the sender to this recipient.  Because persistence is only implemented on the client, this flag is only sent by the server.</t>
+    <t>FLAG_SETTINGS_PERSISTED (0x2):  When set, the sender is notifying the recipient that this ID/Value pair was previously sent to the sender by the recipient with the FLAG_SETTINGS_PERSIST_VALUE, and the sender is returning it.  Because persistence is only implemented on the client, this flag is only sent by the client.</t>
+  </list>
+</t>
+
 <t>ID: 24-bits in network byte order.  Defined IDs:
   <list>
 <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>
@@ -445,13 +450,6 @@
   </list>
 </t>
 
-<t>Flags: An 8 bit value.  Defined Flags:
-  <list>
-    <t>FLAG_SETTINGS_PERSIST_VALUE (0x1):   When set, the sender of this SETTINGS frame is requesting that the recipient persist the ID/Value and return it in future SETTINGS frames sent from the sender to this recipient.  Because persistence is only implemented on the client, this flag is only sent by the server.</t>
-    <t>FLAG_SETTINGS_PERSISTED (0x2):  When set, the sender is notifying the recipient that this ID/Value pair was previously sent to the sender by the recipient with the FLAG_SETTINGS_PERSIST_VALUE, and the sender is returning it.  Because persistence is only implemented on the client, this flag is only sent by the client.</t>
-  </list>
-</t>
-
 <t>Value: A 32-bit value.</t>
 
 <t>The message is intentionally extensible for future information which may improve client-server communications. The sender does not need to send every type of ID/value. It must only send those for which it has accurate values to convey. When multiple ID/value pairs are sent, they should be sent in order of lowest id to highest id.  A single SETTINGS frame MUST not contain multiple values for the same ID.  If the recipient of a SETTINGS frame discovers multiple values for the same ID, it MUST ignore all values except the first one.</t>
@@ -1068,9 +1066,9 @@ const unsigned char SPDY_dictionary_txt[] = {
 <t>It is true that we don't need the UNIDIRECTIONAL markings.  It is added because it avoids the recipient of pushed streams from needing to send a set of empty frames (e.g. the SYN_STREAM w/ FLAG_FIN) which otherwise serve no purpose.</t>
       </section>
       <section title="Data Compression">
-<t>Generic compression of data portion of the streams (as opposed to compression of the headers) without knowing the content of the stream is redundant.  There is no value in compressing a stream which is already compressed.  Because of this, SPDY does allow data compression to be optional.  We included it because study of existing websites shows that many sites are not using compression as they should, and users suffer because of it.  We wanted a mechanism where, at the SPDY layer, site administrators could simply force compression - it is better to compress twice than to not compress.</t>
+<t>Generic compression of data portion of the streams (as opposed to compression of the headers) without knowing the content of the stream is redundant.  There is no value in compressing a stream which is already compressed.  Because of this, SPDY initially allowed data compression to be optional.  We included it because study of existing websites shows that many sites are not using compression as they should, and users suffer because of it.  We wanted a mechanism where, at the SPDY layer, site administrators could simply force compression - it is better to compress twice than to not compress.</t>
 
-<t>Overall, however, with this feature being optional and sometimes redundant, it is unclear if it is useful at all.  We will likely remove it from the specification.</t>
+<t>Overall, however, with this feature being optional and sometimes redundant, it was unclear if it was useful at all.  We removed it from the specification.</t>
       </section>
       <section title="Server Push">
 <t>A subtle but important point is that server push streams must be declared before the associated stream is closed.  The reason for this is so that proxies have a lifetime for which they can discard information about previous streams.  If a pushed stream could associate itself with an already-closed stream, then endpoints would not have a specific lifecycle for when they could disavow knowledge of the streams which went before.</t>