Re: QUIC(ker)

On Fri, 30 Jan 2026 at 02:13, Stephen Paul Weber <[email protected]>
wrote:

> I think we have, with "WebTransport" a real opportunity to specify a
> proper
> XMPP-native transport mechanism (no extra framing or use case specific
> hacks
> like WebSocket or BOSH, full normal TLS support possible when implemented
> in
> a normal client, etc) that happens to also work from browsers (and other
> things like transit through HTTP proxies and HTTP reverse proxies... at
> least if they support http3 smelling things).
>
> I'm not sure what the "raw" QUIC advantages could be, but I would be
> strongly in favour of making this a special case MAY with WebTransport
> handshake support as at least a SHOULD level thing.


For all the purposes I need QUIC for (and Marc Blanchet, too), having full
control over congestion control, keep alives, idle timeouts etc is
important. Web Transport doesn't let you tinker in this way.

Also, Web Transport adds the HTTP/3 handshake, which is breaking the 0-RTT
desire.

I think Web Transport might well be great for many cases, but I'm currently
focused on low-bandwidth, high-latency, high-loss networks, so for my
purposes at least I'm only interested in QUIC itself at this stage.

But, solving QUIC should mean that Web Transport is very easy.

Dave.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]