Reviving this thread for the new year. On Sat, 22 Nov 2025 at 17:24, Michael Welzl <[email protected]> wrote:
> Hi, > > These minutes are great, thanks! Seems like it was an interesting > conversation. > Agreed. My takeaway is that evangelising the benefits of H3 over H2, supported by some new public data, would really help. Data on the problem areas, with advice on how to handle them is also needed. This can then spur development of libraries and encourage shipping with default-on configuration. > Need better tools in programming languages to make it easier to use QUIC. > > FWIW, this is why the TAPS WG existed, see RFCs 9621, 9622, 9623. It > would be great if we could get some momentum towards more implementations, > specifically ones that use QUIC… surely there’s no easier way for people > to access QUIC’s features without having to care about the specifics. > I agree the modern Transport Services API should be encouraged. https://www.rfc-editor.org/rfc/rfc9623.html#name-existing-implementations lists Apple's Network.framework, NEAT and two Python implementations. > I currently have two master students working on implementations that will > use QUIC, but that’s as much as *I* can offer, from the world of academia. > Thank you for that! > PS: there’s also https://github.com/tfpauly/draft-taps-quic-mapping but > it’s going stale… > It strikes me as odd that 9621-9623 didn't include support for 9000. Is there a reason why the QUIC mapping wasn't seen as important? Chris
