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.

Attachment: signature.asc
Description: PGP signature

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

Reply via email to