You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on a dissector for the base HTTP/3 protocol, I ran across 2 and 3. It turns out these are defined in the QPACK document (https://tools.ietf.org/html/draft-ietf-quic-qpack-10#section-8.2) with 2 - QPACK Encoder Stream, 3 - QPACK Decoder Stream.
Since QPACK has already been referenced multiple times from the -http document, what about mentioning (or registering) the two codepoints in the -http document and reference to the -qpack document for the definition?
The text was updated successfully, but these errors were encountered:
We can, and as QPACK is a required component of HTTP/3, you'd probably need to support QPACK for that to work. However, this is an extensible space and your dissector would need to tolerate other types it might not recognize, or that are added by future extensions. So the fact that there are definitions in other documents not mentioned by HTTP/3 is to be expected.
The Stream Types registry (https://tools.ietf.org/html/draft-ietf-quic-http-23#section-11.6) currently lists two types only (0 - control, 1 - push).
While working on a dissector for the base HTTP/3 protocol, I ran across 2 and 3. It turns out these are defined in the QPACK document (https://tools.ietf.org/html/draft-ietf-quic-qpack-10#section-8.2) with 2 - QPACK Encoder Stream, 3 - QPACK Decoder Stream.
Since QPACK has already been referenced multiple times from the -http document, what about mentioning (or registering) the two codepoints in the -http document and reference to the -qpack document for the definition?
The text was updated successfully, but these errors were encountered: