Subject: [quicwg/base-drafts] QPACK: instructions and stream description is suboptimal (#2339)

From: Lucas Pardue <[email-masked]>
Date: Wed, 16 Jan 2019 16:26:28 +0000 (UTC)

Did the section hierarchy get messed up a little in a recent refactor?

The concept of QPACK instructions are first introduced in section 2, along with encoder and decoder streams. There is no forward reference to the later definitions.

The real problem I have is with section 4.2. It contains a bulleted list that is almost identical to section 2, but subtly different. The text following this list is also ambiguous

> There MUST be exactly one of each unidirectional stream type in each direction.
The previous list referred to request streams and push streams. These are obviously out of scope but it could get mistaken.

I think we've discussed elsewhere that implementations could decide not to use dynamic compression, and so the encoder and decoder streams are not necessary. I think this sentence could be made clearer by saying something like "if the dynamic table is being used, each endpoint MUST create exactly one pair of encoder and decoder streams."

> Receipt of a second instance of either stream type MUST be treated as a connection error of HTTP_WRONG_STREAM_COUNT.

Perhaps simplify to "receipt of additional streams which claim to be an encoder or decoder stream MUST be treated as a connection error of HTTP_WRONG_STREAM_COUNT.

> Closure of either unidirectional stream MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.

Perhaps "The closure of encoder or decoder streams, at any point, MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM."

> This section describes the instructions which are possible on each stream type.
No it doesn't :)

While I am here, Section 4.5 is titled "Request and Push Streams" but it just talks about instructions to include in frames. 

I'm left with a feeling that there is a misplaced focus on streams rather than instructions. This could be inverted to state instructions, with a comment on where they are allowed to appear, summarised in a nice table somewhere in the document.

-- 
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/issues/2339

---

From: afrind <[email-masked]>
Date: Wed, 16 Jan 2019 08:35:42 -0800

The big editorial refactor intentionally reordered the sections: the goal was to describe concepts first and specific instructions second.

Regarding whether the encoder/decoder streams are required, there's a separate (design) issue open (#2100). 

Given that the instruction spaces are unique per stream type, and no instruction is allowed on more than one stream, I think it makes sense to keep the instructions organized by the stream on which they are used.  

I can clean up the ambiguous references to unidirectional streams to make it clear that we're talking about the QPACK control streams.

I'll give it another read through with your comments in mind and see what further improvements we can make.

-- 
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/issues/2339#issuecomment-454847187

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 16 Jan 2019 08:53:51 -0800

I'm happy to come up with a PR containing some proposals. 

I think we have some diversity in perspective. Coming from a HTTP/3-first position with a background in HTTP/2, my currency is the _header block_. I've been told it can be sent in HEADERS and PUSH_PROMISE, I don't need to be told how those frames are sent (i.e. what streams).

As someone unfamiliar with the specification, the instructions don't leap out. There is not one section in the TOC that mentions the term _instruction_. From my limited appreciation, I'd class the instructions as a primitive of header compression. But I accept that these are perhaps the QPACK data model, with primitives akin to built-in types. 

It still hasn't leapt out to me if the encoder and decoder stream exchange clear header blocks, or just a stream of instructions.

-- 
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/issues/2339#issuecomment-454854127

---

From: afrind <[email-masked]>
Date: Wed, 16 Jan 2019 17:55:41 +0000 (UTC)

> my currency is the header block. I've been told it can be sent in HEADERS and PUSH_PROMISE, I don't need to be told how those frames are sent (i.e. what streams).

Maybe it would simplify the document to refer to encoder stream, decoder stream and header blocks in that case?

>  I'd class the instructions as a primitive of header compression.

True, much like frames are primitives in transport and HTTP.  Both documents were reorganized as concepts first and wire-specifics following.  Perhaps instructions as a concept aren't explained early enough?  I'd prefer to keep the wire instructions after concepts.

> It still hasn't leapt out to me if the encoder and decoder stream exchange clear header blocks, or just a stream of instructions.

See 4.3 and 4.4

> The contents of the en/decoder stream are an unframed sequence of the following instructions.

-- 
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/issues/2339#issuecomment-454876451

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 20 Jan 2019 15:25:17 -0800

Discussed off list. I'll prepare some PRs that we can discuss.

-- 
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/issues/2339#issuecomment-455912541