Notes from the Summit:
WEBTRANS would also be of interest, but "raw" QUIC has some advantages as
well, so we probably want both with a uniform approach.
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.