Subject: [quicwg/base-drafts] Core terminology in QPACK (#3520)

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Mar 2020 08:02:03 -0700

Companion to #3513, switching QPACK to the updated terminology.  Since HPACK/QPACK has its own terms of art derived from the HTTP terminology, I had to adapt a few.  These are, of course, open for bikeshedding.

In general:
- &quot;headers&quot; =&gt; &quot;fields&quot;
    - ...but what QPACK stores are &quot;field lines,&quot; not &quot;fields&quot;
- &quot;header block&quot; =&gt; &quot;field block&quot;
- &quot;header list&quot; =&gt; &quot;field list&quot;
- &quot;header tables&quot; =&gt; &quot;reference tables&quot;
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3520

-- Commit Summary --

  * QFIELDS!!!

-- File Changes --

    M draft-ietf-quic-qpack.md (349)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3520.patch
https://github.com/quicwg/base-drafts/pull/3520.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Mar 2020 08:08:41 -0700

Also of note:  I haven't messed with the title, but that probably needs to change, too.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#issuecomment-598765864

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 13 Mar 2020 09:18:39 -0700

LPardue approved this pull request.

lgtm modulo nnnits

-After the decoder finishes decoding a header block containing dynamic table
-references, it MUST emit a Header Acknowledgement instruction
-({{header-acknowledgement}}).  A stream may carry multiple header blocks in the
+After the decoder finishes decoding a field block containing dynamic table
+references, it MUST emit a Entry Acknowledgement instruction

```suggestion
references, it MUST emit an Entry Acknowledgement instruction
```

-After processing a header block whose declared Required Insert Count is not
-zero, the decoder emits a Header Acknowledgement instruction.  The instruction
-begins with the '1' one-bit pattern which is followed by the header block's
+After processing a field block whose declared Required Insert Count is not
+zero, the decoder emits a Entry Acknowledgement instruction.  The instruction

```suggestion
zero, the decoder emits an Entry Acknowledgement instruction.  The instruction
```

-If an encoder receives a Header Acknowledgement instruction referring to a
-stream on which every header block with a non-zero Required Insert Count has
+If an encoder receives a Entry Acknowledgement instruction referring to a

```suggestion
If an encoder receives an Entry Acknowledgement instruction referring to a
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#pullrequestreview-374428682

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Mar 2020 12:11:40 -0700

@MikeBishop pushed 1 commit.

21533fbbd8972ef04c76320be7ca05f632b98c98  Find and replace makes grammar errors?  What?

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520/files/1f4f8fffb4733a307ea342b28d3d025be818e544..21533fbbd8972ef04c76320be7ca05f632b98c98

---

From: afrind <[email-masked]>
Date: Fri, 13 Mar 2020 14:11:01 -0700

afrind commented on this pull request.

Thanks for taking a stab at this.  

I haven't been closely following the core work; is it at a point where we think it won't change again and we can adopt it here, or should we wait?  What's our plan if this work is finalized before core, and core changes again?

The term I dislike the most is "field line".  This is a good description of what was there in HTTP/1.x, but with H2+, the concept of a "line" is completely foreign.

-Header block:
+Field list:

Would it be better to call this a Field section, rather than a list?

-: The compressed representation of a header list.
+: An ordered collection of HTTP field lines associated with an HTTP message.  A
+  field list can contain multiple field lines with the same name.  It can
+  also contain duplicate field lines.  The header field and trailer field
+  sections of an HTTP message each contain a field list.
+
+Field block:

Should this be a Section block, or Field Section block?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#pullrequestreview-374610217

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Mar 2020 15:20:07 -0700

4407d622b2ceb9c14afbe356002dd3a848f0558b  Remove list

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520/files/21533fbbd8972ef04c76320be7ca05f632b98c98..4407d622b2ceb9c14afbe356002dd3a848f0558b

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Mar 2020 16:26:46 -0700

MikeBishop commented on this pull request.

I'm wondering if we still need a separate term for this, or if we just call it an "encoded field section."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#discussion_r394027340

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Mar 2020 17:01:03 -0700

mnot commented on this pull request.

I like that

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#discussion_r394037752

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Mar 2020 17:01:28 -0700

mnot approved this pull request.

Looks like a reasonable start

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#pullrequestreview-376483261

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Mar 2020 10:21:37 -0700

24628e3206c49b428a015c3807a9c60f4e161d05  No field blocks

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520/files/4407d622b2ceb9c14afbe356002dd3a848f0558b..24628e3206c49b428a015c3807a9c60f4e161d05

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Mar 2020 10:23:06 -0700

24628e32 takes the route of turning all references to "blocks" into "encoded field sections" or "field sections," as appropriate.  In a few cases, I wound up talking about a "series of field representations" instead.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#discussion_r395194350

---

From: ianswett <[email-masked]>
Date: Sat, 21 Mar 2020 13:00:14 -0700

ianswett commented on this pull request.

> @@ -84,9 +84,10 @@ code and issues list for this draft can be found at
 
 The QUIC transport protocol {{QUIC-TRANSPORT}} is designed to support HTTP
 semantics, and its design subsumes many of the features of HTTP/2 {{?RFC7540}}.
-HTTP/2 uses HPACK {{!RFC7541}} for header compression.  If HPACK were used for
-HTTP/3 {{HTTP3}}, it would induce head-of-line blocking due to built-in
-assumptions of a total ordering across frames on all streams.
+HTTP/2 uses HPACK {{!RFC7541}} for compression of the header and trailer
+sections.  If HPACK were used for HTTP/3 {{HTTP3}}, it would induce head-of-line
+blocking due to built-in assumptions of a total ordering across frames on all

```suggestion
blocking for headers due to built-in assumptions of a total ordering across frames on all
```

> @@ -84,9 +84,10 @@ code and issues list for this draft can be found at
 
 The QUIC transport protocol {{QUIC-TRANSPORT}} is designed to support HTTP
 semantics, and its design subsumes many of the features of HTTP/2 {{?RFC7540}}.
-HTTP/2 uses HPACK {{!RFC7541}} for header compression.  If HPACK were used for
-HTTP/3 {{HTTP3}}, it would induce head-of-line blocking due to built-in
-assumptions of a total ordering across frames on all streams.
+HTTP/2 uses HPACK {{!RFC7541}} for compression of the header and trailer
+sections.  If HPACK were used for HTTP/3 {{HTTP3}}, it would induce head-of-line
+blocking due to built-in assumptions of a total ordering across frames on all

Or maybe better would be ", it would make headers head-of-line blocking due to..."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#pullrequestreview-378946856

---

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Mar 2020 08:17:50 -0700

cc60e57cad1b1279b2b1173fc47d857780e7a88f  for headers, but modern

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520/files/24628e3206c49b428a015c3807a9c60f4e161d05..cc60e57cad1b1279b2b1173fc47d857780e7a88f

---

From: Bence Béky <[email-masked]>
Date: Thu, 26 Mar 2020 05:28:20 -0700

@bencebeky requested changes on this pull request.

LGTM modulo nits.

 Encoder:
 
-: An implementation which transforms a header list into a header block.
+: An implementation which transforms a field section into a series of

I don't think "series of representations" is appropriate here.  In particular, is the header block prefix a representation?  It does not represent any fields or field lines, and the sentence "An encoded field section consists of a prefix and a possibly empty sequence of representations defined in this section" also implies that the prefix is not a representation.

How about this instead:
"Encoder: An implementation that encodes field sections.
Decoder: An implementation that decodes valid QPACK-encoded field sections."?

 Encoder:
 
-: An implementation which transforms a header list into a header block.
+: An implementation which transforms a field section into a series of

"a field section" should probably be plural, because encoders and decoders typically transform multiple field sections.

-QPACK preserves the ordering of header fields within each header list.  An
-encoder MUST emit header field representations in the order they appear in the
-input header list.
+QPACK preserves the ordering of field lines within each field section.  An
+encoder MUST emit field representations in the order they appear in the input
+field list.

Maybe "field section" instead of "field list", because "field list" is not defined in SEMANTICS.

> @@ -273,20 +285,20 @@ permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS, compression efficiency
 can often be improved by referencing dynamic table entries that are still in
 transit, but if there is loss or reordering the stream can become blocked at the
 decoder.  An encoder can avoid the risk of blocking by only referencing dynamic
-table entries which have been acknowledged, but this could mean using
-literals. Since literals make the header block larger, this can result in the
-encoder becoming blocked on congestion or flow control limits.
+table entries which have been acknowledged, but this could mean using literals.
+Since literals make the encoding of the field section larger, this can result in

"Encoding of the field section" makes one think of the process rather than the binary result.  "Encoded field section" might be more appropriate here.

-While blocked, header block data SHOULD remain in the blocked stream's flow
+While blocked, field section data SHOULD remain in the blocked stream's flow

Consider writing "encoded field section" instead of "field section".  Header block and header list were distinct things, and they got renamed to "encoded field section" and "field section" respectively.  Therefore "encoded field section" is not a kind of "field section", but a different concept.

> @@ -1130,8 +1141,8 @@ The following error codes are defined for HTTP/3 to indicate failures of
 QPACK which prevent the connection from continuing:
 
 QPACK_DECOMPRESSION_FAILED (0x200):
-: The decoder failed to interpret a header block and is not able to continue
-  decoding that header block.
+: The decoder failed to interpret a representation and is not able to continue

Consider writing "an encoded field section" instead of "a representation" to include errors interpreting data in prefix.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520#pullrequestreview-381942851

---

From: Mike Bishop <[email-masked]>
Date: Fri, 27 Mar 2020 11:27:50 -0700

29f72455a27655d24041d9df01e5d86d042d1106  Bence's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3520/files/cc60e57cad1b1279b2b1173fc47d857780e7a88f..29f72455a27655d24041d9df01e5d86d042d1106