Hi Isa, Please see responses in-line:
On Sat, Oct 12, 2024, at 23:14, Isa Jafarov wrote: > Good day. > > I would like to point out an issue about RFC 9204 (QPACK). > > Here is a quote from RFC 9204 (QPACK): > *- An encoder stream is a unidirectional stream of type 0x02. It carries an > unframed sequence of encoder instructions from encoder to decoder.* > *- A decoder stream is a unidirectional stream of type 0x03. It carries an > unframed sequence of decoder instructions from decoder to encoder.* > > In RFC 9000 (QUIC), we see that stream type 0x02 is only for Unidirectional > Client-Initiated streams and 0x03 is for Unidirectional Server-Initiated > streams. Based on this information, one can conclude that an encoder stream > can only be created by the client and a decoder stream can only be created by > the server. However, it contradicts the fact that each peer can open both > encoder and decoder streams. Even in practice, we can see servers opening > encoder streams on stream #7 and clients opening decoder streams on stream > #10. > > Is there something wrong with the stream types or do I miss something here? QPACK runs on HTTP/3 connections. HTTP/3 defines the concept of unidirection stream types [1], this is distinct from the QUIC stream type [2] >From RFC 9114 Section 6.2 > Unidirectional streams, in either direction, are used for a range of > purposes. The purpose is indicated by a stream type, which is sent as a > variable-length integer at the start of the stream. The text in QPACK is speaking directly about the value sent at the start of the unidirectional stream - encoder stream using 0x2, decoder stream using 0x3. Hope that helps. Cheers, Lucas [1] - https://datatracker.ietf.org/doc/html/rfc9114#section-6.2 [2] - https://datatracker.ietf.org/doc/html/rfc9000#section-2.1 > > Best regards, > -Isa
