On Tue, Mar 24, 2026, at 21:06, Kazuho Oku wrote: > * it avoids requiring the decoder of every frame type to support trial > or incremental decoding to handle truncated input;
As I said, while you might simplify, but in doing so you introduce performance penalties that ultimately lead you back to having to handle incremental decoding. That this is an option is potentially valuable and an argument in favor, I wouldn't weight it too much. However, frame decoding is such a small part of an implementation that I see this as less of a problem than you are making out. > * the overhead is identical when sending large data; and Not entirely correct, but it's very close. When the length spans more (the "record" length always includes at least a STREAM frame header) there is a chance that the varint needs more bytes. So it will be every so slightly higher overhead. > * it naturally reduces the risk of blocking caused by frames crossing > TLS record boundaries. I don't think this is right. If you are blocking on the "record" being complete, any problem will be *worse*, not better if the "record" spans more bytes. > Put differently, I think QMux records provide a structure that is > easier to implement efficiently across QMux stacks. As noted in my previous message, I think that this hides complexity and makes blocking worse. An efficient implementation will need to engage with incremental decoding regardless of any framing layer. It's a small thing, and it's not a blocker for me, but I am mildly opposed to the change.
