Re: QUIC(ker)

On Sun, 5 Apr 2026 at 04:49, Travis Burtrum <[email protected]> wrote:

>
>
> On April 4, 2026 5:23:40 PM EDT, Dave Cridland <[email protected]> wrote:
> >On Fri, 30 Jan 2026 at 04:19, Travis Burtrum <[email protected]> wrote:
> >
> >> Nothing in the current XEP  https://xmpp.org/extensions/xep-0467.html
> >> forbids multiple streams, in fact it mentions it directly
> >>
> >> > Multiple bi-directional MAY be opened in one session and MUST be
> treated
> >> as a seperate connections with the same security and authentication as
> >> negotiated in the initial TLS handshake. This means clients can log into
> >> multiple accounts, or the same account multiple times over one QUIC
> >> session, or servers can open multiple s2s connections over one QUIC
> session
> >> where one of the servers can prove control over multiple domains, for
> >> example if the certificate covered multiple domain names.
> >>
> >
> >I took this to mean ... well, actually I'm not sure what this means. So
> >clients can open multiple bi-directional reliable streams, they must be
> >treated as seperate connections but with the same security and
> >authentication? What does "separate connections" mean if they're
> >authenticated the same? Are they the same resource on a C2S? Does the S2S
> >mention suggest that each domain pair MUST (MIGHT?) be on a different
> >stream, and that we SHOULDN'T mix them?
> >
> >I think this needs a massive amount more detail.
>
> The same security and authentication of the TLS negotiation, so if you are
> a client with a connection to a server with a cert you trust that is good
> for bob.com and tom.com you can open new quic streams for any number of
> accounts on those domains. But not google.com.  tl;dr only trust your TLS
> auth when deciding if you can use the connection for this domain.
> (different XEPs and RFCs might change the way you trust of course)
>
>
So they go through SASL etc and form a complete XMLStream on each
connection, under your model? For client sessions, this would mean multiple
resources? This seems very wasteful.

Dave.

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