Merge branch 'master' into move-version

README.md

@@ -27,11 +27,11 @@ QUIC protocol suite.
 * [Working Group Draft](https://tools.ietf.org/html/draft-ietf-quic-http)
 * [Compare Working Group Draft and Editor's copy](https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-http&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-http.txt)
 
-## QCRAM
+## QPACK
 
-* [Editor's copy](https://quicwg.github.io/base-drafts/draft-ietf-quic-qcram.html)
-* [Working Group Draft](https://tools.ietf.org/html/draft-ietf-quic-qcram)
-* [Compare Working Group Draft and Editor's copy](https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qcram&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-qcram.txt)
+* [Editor's copy](https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.html)
+* [Working Group Draft](https://tools.ietf.org/html/draft-ietf-quic-qpack)
+* [Compare Working Group Draft and Editor's copy](https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-qpack&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-qpack.txt)
 
 ## Building the Draft
 

draft-ietf-quic-http.md

@@ -38,11 +38,11 @@ normative:
         org: Mozilla
         role: editor
 
-  QCRAM:
-    title: "Header Compression for HTTP over QUIC"
+  QPACK:
+    title: "QPACK: Header Compression for HTTP over QUIC"
     date: {DATE}
     seriesinfo:
-      Internet-Draft: draft-ietf-quic-qcram-latest
+      Internet-Draft: draft-ietf-quic-qpack-latest
     author:
       -
           ins: C. Krasic
@@ -344,7 +344,7 @@ abort a response in progress as a result of receiving a solicited RST_STREAM.
 
 ### Header Compression
 
-HTTP/QUIC uses QCRAM header compression as described in [QCRAM], a variation of
+HTTP/QUIC uses QPACK header compression as described in [QPACK], a variation of
 HPACK which allows the flexibility to avoid header-compression-induced
 head-of-line blocking.  See that document for additional details.
 
@@ -554,7 +554,7 @@ with a payload length of zero, the recipient MUST respond with a stream error
 ### HEADERS {#frame-headers}
 
 The HEADERS frame (type=0x1) is used to carry a header block, compressed using
-QCRAM. See [QCRAM] for more details.
+QPACK. See [QPACK] for more details.
 
 The HEADERS frame defines a single flag:
 
@@ -844,7 +844,7 @@ Push ID:
   ({{frame-cancel-push}}), and PRIORITY frames ({{frame-priority}}).
 
 Header Block:
-: QCRAM-compressed request headers for the promised response.  See [QCRAM] for
+: QPACK-compressed request headers for the promised response.  See [QPACK] for
   more details.
 
 A server MUST NOT use a Push ID that is larger than the client has provided in a
@@ -976,16 +976,16 @@ HTTP_NO_ERROR code.
 ### HEADER_ACK {#frame-header-ack}
 
 The HEADER_ACK frame (type=0x8) is used by header compression to ensure
-consistency. The frames are sent from the QCRAM decoder to the QCRAM encoder;
+consistency. The frames are sent from the QPACK decoder to the QPACK encoder;
 that is, the server sends them to the client to acknowledge processing of the
 client's header blocks, and the client sends them to the server to acknowledge
 processing of the server's header blocks.
 
-The HEADER_ACK frame is sent on the Control Stream when the QCRAM decoder has
-fully processed a header block.  It is used by the peer's QCRAM encoder to
+The HEADER_ACK frame is sent on the Control Stream when the QPACK decoder has
+fully processed a header block.  It is used by the peer's QPACK encoder to
 determine whether subsequent indexed representations that might reference that
 block are vulnerable to head-of-line blocking, and to prevent eviction races.
-See [QCRAM] for more details on the use of this information.
+See [QPACK] for more details on the use of this information.
 
 The HEADER_ACK frame indicates the stream on which the header block was
 processed by encoding the Stream ID as a variable-length integer. The same
@@ -1190,7 +1190,7 @@ Likewise, HPACK was designed with the assumption of in-order delivery. A
 sequence of encoded header blocks must arrive (and be decoded) at an endpoint in
 the same order in which they were encoded. This ensures that the dynamic state
 at the two endpoints remains in sync.  As a result, HTTP/QUIC uses a modified
-version of HPACK, described in [QCRAM].
+version of HPACK, described in [QPACK].
 
 Frame type definitions in HTTP/QUIC often use the QUIC variable-length integer
 encoding.  In particular, Stream IDs use this encoding, which allow for a larger

draft-ietf-quic-invariants.md

@@ -142,9 +142,9 @@ version-specific semantics are marked with an X.
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |DCIL(4)|SCIL(4)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|               Destination Connection ID (0/64..176)         ...
+|               Destination Connection ID (0/32..144)         ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                 Source Connection ID (0/64..176)            ...
+|                 Source Connection ID (0/32..144)            ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X  ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -157,21 +157,23 @@ All other bits in that octet are version specific.
 The next four octets include a 32-bit Version field (see {{version}}).
 
 The next octet contains the length in octets of the two Connection IDs (see
-{{connection-id}}) that follow.  Each length is encoded as a 4 bit unsigned
+{{connection-id}}) that follow.  Each length is encoded as a 4-bit unsigned
 integer.  The length of the Destination Connection ID (DCIL) occupies the high
 bits of the octet and the length of the Source Connection ID (SCIL) occupying
 the low bits of the octet.  An encoded length of 0 indicates that the connection
-ID is also 0 octets in length.  Non-zero encoded lengths are increased by 7 to
-get the full length of the connection ID.  For example, an octet with the value
-0xa0 describes a 17 octet Destination Connection ID and a zero octet Source
-Connection ID.
+ID is also 0 octets in length.  Non-zero encoded lengths are increased by 3 to
+get the full length of the connection ID; the final value is therefore either 0
+or between 4 and 18 octets in length (inclusive).  For example, an octet with
+the value 0xe0 describes a 17 octet Destination Connection ID and a zero octet
+Source Connection ID.
 
 The connection ID lengths are followed by a two connection IDs.  The connection
 ID associated with the recipient of the packet (the Destination Connection ID)
 is followed by the connection ID associated with the sender of the packet (the
 Source Connection ID).
 
-The remainder of the packet contains version-specific content.
+The Connection IDs are followed by a 32-bit Version (see {{version}}) and a
+version-specific payload.
 
 
 ## Short Header
@@ -185,7 +187,7 @@ version-specific semantics are marked with an X.
 +-+-+-+-+-+-+-+-+
 |0|X X X X X X X|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                Destination Connection ID (0..176)           ...
+|                Destination Connection ID (0..144)           ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X  ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -194,17 +196,17 @@ version-specific semantics are marked with an X.
 
 A QUIC packet with a short header has the high bit of the first octet set to 0.
 
-A QUIC packet with a short header includes a Destination Connection ID.  The
-short header does not include the Connection ID Lengths, Source Connection ID,
-or Version fields.
+A QUIC packet with a short header includes an optional Destination Connection
+ID.  The short header does not include the Connection ID Lengths, Source
+Connection ID, or Version fields.
 
 The remainder of the packet has version-specific semantics.
 
 
 ## Connection ID
 
 A connection ID is an opaque field.  A connection ID can be 0 octets in length,
-or between 8 and 22 octets (inclusive).
+or between 4 and 18 octets (inclusive).
 
 The primary function of a connection ID is to ensure that changes in addressing
 at lower protocol layers (UDP, IP, and below) don't cause packets for a QUIC
@@ -250,9 +252,9 @@ Version field, which is set to 0x00000000.
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |DCIL(4)|SCIL(4)|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|               Destination Connection ID (0/64..176)         ...
+|               Destination Connection ID (0/32..144)         ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                 Source Connection ID (0/64..176)            ...
+|                 Source Connection ID (0/32..144)            ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Supported Version 1 (32)                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -276,12 +278,13 @@ Version Negotiation packets do not use integrity or confidentiality protection.
 A specific QUIC version might authenticate the packet as part of its connection
 establishment process.
 
-The Connection ID fields in a Version Negotiation packet contain the Connection
-ID values from the packet that was received by the server, inverted to ensure
-correct routing of the packet toward the client based on the Destination
-Connection ID.  Echoing the value of the client's Destination Connection ID in
-the Source Connection ID field can provide some protection against injection of
-Version Negotiation packets by off-path attackers.
+The server MUST include the value from the Source Connection ID field of the
+packet it receives in the Destination Connection ID field.  The value for Source
+Connection ID MUST be copied from the Destination Connection ID of the received
+packet, which is initially randomly selected by a client.  Echoing both
+connection IDs gives clients some assurance that the server received the packet
+and that the Version Negotiation packet was not generated by an off-path
+attacker.
 
 An endpoint that receives a Version Negotiation packet might change the version
 that it decides to use for subsequent packets.  The conditions under which an

draft-ietf-quic-qcram.md → draft-ietf-quic-qpack.md

@@ -1,7 +1,7 @@
 ---
-title: Header Compression for HTTP over QUIC
-abbrev: QCRAM
-docname: draft-ietf-quic-qcram-latest
+title: "QPACK: Header Compression for HTTP over QUIC"
+abbrev: QPACK
+docname: draft-ietf-quic-qpack-latest
 date: {DATE}
 category: std
 ipr: trust200902
@@ -32,7 +32,7 @@ author:
 
 --- abstract
 
-This specification defines QCRAM, a compression format for efficiently
+This specification defines QPACK, a compression format for efficiently
 representing HTTP header fields, to be used in HTTP over QUIC. This is a
 variation of HPACK header compression that seeks to reduce head-of-line
 blocking.
@@ -45,7 +45,7 @@ Discussion of this draft takes place on the QUIC working group mailing list
 
 Working Group information can be found at <https://github.com/quicwg>; source
 code and issues list for this draft can be found at
-<https://github.com/quicwg/base-drafts/labels/-qcram>.
+<https://github.com/quicwg/base-drafts/labels/-qpack>.
 
 --- middle
 
@@ -70,13 +70,13 @@ mapping is described in {{!QUIC-HTTP=I-D.ietf-quic-http}}. For a full
 description of HTTP/2, see {{?RFC7540}}. The description of HPACK is
 {{!RFC7541}}, with important terminology in Section 1.3.
 
-QCRAM modifies HPACK to allow correctness in the presence of out-of-order
+QPACK modifies HPACK to allow correctness in the presence of out-of-order
 delivery, with flexibility for implementations to balance between resilience
 against HoL blocking and optimal compression ratio.  The design goals are to
 closely approach the compression ratio of HPACK with substantially less
 head-of-line blocking under the same loss conditions.
 
-QCRAM is intended to be a relatively non-intrusive extension to HPACK; an
+QPACK is intended to be a relatively non-intrusive extension to HPACK; an
 implementation should be easily shared within stacks supporting both HTTP/2 over
 (TLS+)TCP and HTTP/QUIC.
 
@@ -188,7 +188,7 @@ change (implicitly).  Implicit index updates are acceptable for HTTP/2 because
 TCP is totally ordered, but are problematic in the out-of-order context of
 QUIC.
 
-QCRAM uses a hybrid absolute-relative indexing approach.
+QPACK uses a hybrid absolute-relative indexing approach.
 
 When the encoder adds a new entry to its header table, it can compute
 an absolute index:
@@ -209,7 +209,7 @@ indices:
 Header blocks on request and push streams do not modify the dynamic table state,
 so they never change the `baseIndex`.  However, since ordering between streams
 is not guaranteed, the value of `baseIndex` can not be synchronized implicitly.
-Instead then, QCRAM sends encoder's `Base Index` explicitly as part of the
+Instead then, QPACK sends encoder's `Base Index` explicitly as part of the
 prefix (see {{absolute-index}}), so that the decoder can compute the same
 absolute indices that the encoder used:
 
@@ -225,9 +225,9 @@ with the `HTTP_HPACK_DECOMPRESSION_FAILED` error code.
 
 ## Preventing Eviction Races {#evictions}
 
-Due to out-of-order arrival, QCRAM's eviction algorithm requires changes
+Due to out-of-order arrival, QPACK's eviction algorithm requires changes
 (relative to HPACK) to avoid the possibility that an indexed representation is
-decoded after the referenced entry has already been evicted.  QCRAM employs a
+decoded after the referenced entry has already been evicted.  QPACK employs a
 two-phase eviction algorithm, in which the encoder will not evict entries that
 have outstanding (unacknowledged) references.
 
@@ -291,7 +291,7 @@ space efficient.
 
 ### Safe evictions
 
-Section {{evictions}} describes how QCRAM avoids invalid references that might
+Section {{evictions}} describes how QPACK avoids invalid references that might
 result from out-of-order delivery.  When the encoder processes a HEADER_ACK, it
 dereferences table entries that were indexed in the acknowledged header.  To
 track which entries must be dereferenced, it can maintain a map from
@@ -326,9 +326,9 @@ the number of concurrently blocked streams.
 ### Fixed overhead.
 
 HPACK defines overhead as 32 bytes ({{!RFC7541}}, Section 4.1).  As described
-above, QCRAM adds some per-connection state, and possibly some per-entry state
+above, QPACK adds some per-connection state, and possibly some per-entry state
 to track acknowledgment status and eviction reference count.  A larger value
-than 32 might be more accurate for QCRAM.
+than 32 might be more accurate for QPACK.
 
 # Security Considerations