Re: [quicwg/base-drafts] QPACK editorial revision (#2759)

[afrind <[e-mail]>]

afrind commented on this pull request.

Thanks for the comments all!

>  
 ### State Synchronization
 
-The decoder instructions ({{decoder-instructions}}) signal key events at the
-decoder that permit the encoder to track the decoder's state.  These events are:
+The decoder signals the following key events by emitting decoder instructions
+({{decoder-instructions}}) on the decoder stream.
+
+#### Completed Processing of a Header Block
+
+When the decoder finishes decoding a header block containing dynamic table
+references, it emits a Header Acknowledgement instruction
+({{header-acknowledgement}}).  The same Stream ID can be identified by multiple
+Header Acknowledgement instructions, as multiple header blocks can be sent on a
+single stream in the case of intermediate responses, trailers, and pushed
+requests.  Since frames carrying header blocks on each stream are received and
+processed in order, this gives the encoder precise feedback on which header
+blocks within a stream have been fully processed.

There isn't a requirement in QPACK that the blocks are "processed" in the order they are received on the stream -- that's an HTTP requirement.  I think I should change this to something else, that indicates that the encoder must interpret the acknowledgements in the order the frames were sent.  I came up with this, but it feels like it could use a MUST or MUST NOT in there:

"The encoder interprets each Header Acknowledgement instruction as acknowledging the earliest unacknowledged header block containing dynamic table references sent on the
given stream."

> +
+When the decoder finishes decoding a header block containing dynamic table
+references, it emits a Header Acknowledgement instruction
+({{header-acknowledgement}}).  The same Stream ID can be identified by multiple
+Header Acknowledgement instructions, as multiple header blocks can be sent on a
+single stream in the case of intermediate responses, trailers, and pushed
+requests.  Since frames carrying header blocks on each stream are received and
+processed in order, this gives the encoder precise feedback on which header
+blocks within a stream have been fully processed.
+
+#### Abandonment of a Stream
+
+When an endpoint receives a stream reset before the end of a stream or before
+all header blocks are processed on that stream, or when it abandons reading of a
+stream, it generates a Stream Cancellation instruction (see
+{{stream-cancellation}}).  This signals to the encoder that all references to

This is old language (see line 825 in the old spec).  I'm not clear on what is unclear.

> @@ -1035,17 +1038,19 @@ values that are not to be put at risk by compressing them (see Section 7.1 of
 ~~~~~~~~~~
 {: title="Literal Header Field With Name Reference"}
 
-For entries in the static table or in the dynamic table with an absolute index
-less than the Base, the header field name is represented using the relative
-index of that entry, which is represented as an integer with a 4-bit prefix (see
-Section 5.1 of [RFC7541]). The `S` bit indicates whether the reference is to the
-static (S=1) or dynamic (S=0) table.
+The fourth (`S`) bit indicates whether the reference is to the static (S=1) or
+dynamic (S=0) table.  Finally, the header field name is represented using the
+static or relative index of that entry, which is represented as an integer with

I added one sentence in the static table section describing the index.  I also normalized the three instructions that have an S bit to all use similar language.  For header block instructions, do I need to specify that 'relative' indexes are relative to Base from the enclosing header block?  Is it sufficient to just say 'relative' or 'relative to Base'?

>  
 An encoder MUST NOT insert an entry into the dynamic table (or duplicate an
-existing entry) if doing so would evict a blocking entry.  In this case, the
-encoder can send literal representations of header fields.
+existing entry) if doing so would evict a blocking entry.  An encoder can always
+send literal representations of header fields when the dynamic table is full

I'm going to try omitting the entire sentence.  People will figure out that they should send a literal?

-- 
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/2759#pullrequestreview-253702347