Re: [quicwg/base-drafts] Allow not creating QPACK codec streams (#2529)

[afrind <[e-mail]>]

afrind commented on this pull request.



>  HTTP_WRONG_STREAM_COUNT. These streams MUST NOT be closed. Closure of either
 unidirectional stream type MUST be treated as a connection error of type
 HTTP_CLOSED_CRITICAL_STREAM.
 
+An endpoint MAY avoid creating its own encoder stream if the maximum size of

@LPardue : The explicit signal is the arrival of a Set Dynamic Table Capacity instruction on the encoder stream with a non-zero capacity (or perhaps the arrival of a header block with a non-zero Required Insert Count, if there's reordering or loss).  I don't see any problem with this - what's the specific concern?

It's actually an improvement over HPACK, where the receiver assumes the sender will use the table by virtue of the non-zero default max capacity.  Implementations that never use the dynamic table might not be kind enough to send an Update Table Size with size=0.

For the language here, would it read better the other way around: 

"The encoder need only open the encoder stream if it wishes to use the dynamic table and is permitted to do so by the decoder" - or something to that effect?

>  HTTP_WRONG_STREAM_COUNT. These streams MUST NOT be closed. Closure of either
 unidirectional stream type MUST be treated as a connection error of type
 HTTP_CLOSED_CRITICAL_STREAM.
 
+An endpoint MAY avoid creating its own encoder stream if the maximum size of
+the dynamic table permitted by the peer is zero.
+
+An endpoint MAY avoid creating its own decoder stream if the maximum size of
+its own dynamic table is zero.
+
+An endpoint MUST allow its peer to create both encoder and decoder streams

> Both clients and servers SHOULD send a value of three or greater for the QUIC transport parameter initial_max_uni_streams.

I think the current consensus regarding QPACK streams is that you cannot prevent their creation, so clients and servers MUST give 3 or more.  If we allow the peer to limit to one unidirectional stream, there's potentially nothing from stopping an implementation from using that to create an encoder or decoder stream.

-- 
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/2529#discussion_r267522635