On Tue, 29 Sept 2026 at 13:19, Travis Burtrum <travis@burtrum.org> wrote:
*sigh* despite repeated requests to simply add any negotiation to allow using this with <https://xmpp.org/extensions/xep-0467.html> which is already long deployed and has different still valid use-cases, this instead doesn't and hi-jacks ALPN values and SRV records. I certainly hope it won't be approved this way, it would be the equivalent of accepting a new XEP using an existing one's namespace, and why?
This problem can be trivially solved any number of ways, the simplest which prevents using both on the same QUIC connection would be just picking new ALPN values. I personally think it'd be cleaner to negotiate this using stream features instead so eg I can log into multiple accounts (c2s) or have traffic from multiple domains (s2s) go over the same QUIC connection.
It can't be stream features, that would entail adding a round-trip. I've enabled the same with a stream prefix (similar to how WebTransport handles it), and that does actually mean you could trivially run both XEP-0467 and this ProtoXEP on the same port by snooping the first octet off the wire. I'm fine with just changing the ALPN, would welcome suggestions. Could just go for "xmpp", and have S2S and C2S handled by the stream open. Note that it's absolutely, 100%, covering your particular use case of handling multiple independent C2S/S2S connections. The latter isn't of use at all, due to piggybacking in existing cases, but multiple C2S for those with multiple accounts on the same server will work fine. This is a side-effect of the stream prefixing design, which also (eventually) buys us things like inline media or file transfer.
If that is solved, then there are other problems with the spec that could be solved after assigning a number. Namely: 1. mentioning web transport without any way to discover/use
True, though BOSH, XMPP over Websocket, and indeed XEP-0467 don't mandate a discovery either, so that's not a big deal. I imagined it would go into some other spec.
2. adding yet more discovery methods when <https://xmpp.org/extensions/xep-0487.html> would allow discovery of this along with the others and also work with web clients and webtransport
Web clients are never ever going to use QUIC, so that's irrelevant. Also, SRV isn't a new discovery method, it's just adding to an existing one.
On September 29, 2026 5:51:55 AM EDT, Daniel Gultsch <daniel@gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Multistream XMPP Abstract: Multistream protocols such as QUIC and WebTransport offer significant performance improvements to XMPP, particularly over constrained or degraded networks. This specification defines a binding for the XMLStream onto multistream transports, including both QUIC and WebTransport.
URL: https://xmpp.org/extensions/inbox/xmpp-quic-redux.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. ________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org