Initial submission.
Baseline XMPP, as defined in XMPP Core
More advanced protocols, such as QUIC (RFC 9000
QUIC provides other benefits, including lower round-trip count for connection, and allows the client connection to migrate as the client switches network layer.
Note that this specification broadly discusses QUIC, but the general approach also maps to WebTransport. Particular differences are noted in the "QUIC vs WebTransport" section.
This specification refers to "streams" quite a lot. XMPP has an XMLStream - this specification uses that term exclusively to mean the logical XMLStream of an "XMPP session". QUIC has a connection, which is referred to as a "QUIC connection", which in turn contains one or more "QUIC streams".
This has the result that WebTransport's subsidiary streams are also, in this specification, referred to as QUIC streams (which they behave broadly identically to).
Also, the term "Bare JID Pair" is introduced. This is the tuple of (from-bare-jid, to-bare-jid), where from-bare-jid is the bare JID of the stanza's from JID, and to-bare-jid is the bare JID of the stanza's to JID.
The requirements for this protocol are simple - it should preserve the existing XMPP semantics visible to the user whether the XMPP connection (or another connection on the route, for example an S2S connection) is negotiated over TCP or QUIC.
In the degenerate case, where only one QUIC stream is used, using QUIC follows the same pattern as the TCP binding. The client opens a connection, negotiating TLS (which is inherently part of QUIC), and sends <stream:stream>, <authenticate/> (from Extensible SASL Profile (XEP-0388)
However, under QUIC, both peers MAY at any time open additional QUIC streams. Each QUIC stream has a type associated with it, provided by this specification, and also an ID provided by the baseline QUIC specification.
Both bidirectional and unidirectional QUIC streams are used within this specification, and additionally QUIC datagrams - also sent on the QUIC connection - can be used.
Each QUIC stream opened, including the first such QUIC stream, has a type associated with it. This type is sent as a QUIC varint (see RFC 9000
There are two stream types that, collectively, map to a single logical XMLStream.
It is possible to open multiple Primary QUIC Streams, leading to multiple independent logical XMLStreams which share only the transport context (including TLS) - though this is not possible on WebTransport.
The type of a Primary QUIC stream is 0.
The header for this type consists of the type value alone.
A Primary QUIC stream MUST be bidirectional, and consists of the normal XMLStream data. A Primary QUIC stream will usually be opened by the initiating entity as the first QUIC stream opened, though other Primary QUIC Streams MAY be opened at any time.
After stream opening, each top-level element from the Primary QUIC stream is processed by parsing a complete element at a time and inserting it into the logical XMLStream.
The type of an Ancillary QUIC stream is 1.
The header for this type consists of the type value, followed immediately by the "Session ID", which for QUIC is the QUIC stream ID of the parent Primary QUIC stream.
An Ancillary QUIC stream can be unidirectional or bidirectional, and is processed by parsing a complete stanza at a time and inserting it into the logical XMLStream. Receivers SHOULD defer processing of stanzas until the parent Primary QUIC stream has been fully authenticated and (for C2S) bound.
Senders MUST only send stanzas; no other top-level elements may be sent on an Ancillary QUIC stream. No stream open or stream close need be sent either. The octets of each stanza are simply logically inserted into the parent. XML namespaces and other context from the XMLStream are processed within that context.
If a sender opens a bidirectional Ancillary QUIC stream, the receiver MAY use it as an Ancillary QUIC stream.
All XMLStream state affects all XMPP QUIC streams making up the logical XMLStream.
Authentication in particular is the concern of the Primary QUIC Stream, and an Ancillary QUIC Stream carries the same authentication state as its parent.
Receivers MUST process each stanza from any XMPP QUIC stream in the order it was sent on that stream, but there are no ordering requirements for stanzas sent on different XMPP QUIC streams. Senders MUST NOT assume that merely "sending first" on one QUIC stream will cause the receiving entity to process that stanza before others sent later on different QUIC streams.
As an example, if a sender sends stanza A1 on the Primary, and then B1, followed by B2, on the same Ancillary, the receiver MUST process B1 before B2, but MAY process A1 before B1, or after B2, or between the two. "Processing", in this case, also includes forwarding onto other XMPP entities (clients or servers).
Senders MAY send any stanza on any XMPP QUIC stream, but MUST NOT allow this to alter any implied ordering between stanzas sent with the same source bare JID and the same destination bare JID.
Thus an XMPP server forwarding two stanzas from and to the same bare JIDs (i.e., the same Bare JID Pair) received over the same XMPP QUIC stream or the same TCP-bound XMLStream MUST maintain their order by retransmitting on a single XMPP QUIC stream; but if they were received over different XMPP QUIC streams or TCP connections there is no such constraint.
Open Question: Other stream types? Media over QUIC, file uploads, blob transport? Or leave those to another spec?
Because of multiple streams, the state of the XMLStream cannot be captured with a simple counter. This means that Stream Management (XEP-0198)
Luckily, QUIC provides its own mechanism equivalent to resumption. QUIC connections can remain dormant for as long as the peers agree to, and be recovered later from the same or a different client-side IP address. For stanza-level acknowledgements, however, there is no equivalent immediately available.
On QUIC, QUIC's own packet-level acknowledgement can be used by senders to achieve a similar "single-tick" effect to that of Stream Management (XEP-0198)
Open Question: What about WebTransport in the browser, then? We probably need an application-level ack, like Stream Management (XEP-0198)
For QUIC itself, clients discover QUIC endpoints using SRV, with a label of _xmpp-client._quic. Servers, similarly, use a label of _xmpp-server._quic.
Open Question: No WebTransport here, and we should probably use SVCB instead.
No default port is defined by this specification. Implementations are free to run all services on the same port, or use different ports for each.
Which protocol is used MUST be negotiated via ALPN, using the ALPN labels as defined by SRV records for XMPP over TLS (XEP-0368)
WebTransport is essentially a mechanism for offering, within an HTTP/2 or HTTP/3 connection, the same facilities of multiple subordinate streams and datagrams as QUIC offers. Overhead, relative to QUIC, is a short HTTP exchange to negotiate the WebTransport session, and some additional "stream header" data.
It is reasonably simple to support alongside QUIC, but is best suited to operating from within a web browser.
While all facilities of QUIC from a structural point of view are available within WebTransport, the lower levels are not exposed to the browser sandbox, and therefore some capabilities are more limited.
But in general terms, wherever this specification refers to a "QUIC stream", it can also refer to a "WebTransport stream".
Stanza-level acknowledgements cannot be inferred by the browser's WebTransport API.
Some kind of path is needed. If the HTTP/3 endpoint is a minimalist shim over a QUIC transport, it can be ignored.
WebTransport does not expose the QUIC stream ids to the sandbox, and therefore cannot be used to open multiple Primary QUIC Streams. Instead, it is possible to simply open multiple WebTransport sessions to achieve the same effect.
Due to the above, the WebTransport "Session ID" is always the octet 0.
The ordering rules defined in this specification are relatively permissive. A server might, for example, send "bulk" traffic like a MAM response over a different XMPP QUIC stream to that used for "live" traffic, and similarly for other types of traffic. Because XMPP Core
The biggest change is the introduction of the Bare JID Pair relative ordering. Servers are forbidden, in this specification, from splitting out the MAM traffic of remote servers (for example, XEP-0045 rooms' archives) from a single stream into multiple streams - this may in practice be safe, but requires further experimentation.
By far the simplest algorithm to remain compliant with this specification is to map each Bare JID Pair to a single XMPP QUIC stream outbound. Multiple Bare JID Pairs can be mapped to a single XMPP QUIC stream. This design results in each direction of a conversation being solely on a single stream (and often, on their own stream), ensuring that message ordering remains stable.
There is no expectation that a stanza sent over a particular XMPP QUIC stream will be responded to (such as errors or IQ results) over the same XMPP QUIC stream.
This specification relies on the implementation having access to QUIC's own packet-level acknowledgements. This has proven possible, and broadly takes the place of Stream Management (XEP-0198)
However, when using a native QUIC stack, the application can track whether individual stanzas have been received by the peer, and can use this information for "single-tick" or similar, without any overhead at the application level. In low-bandwidth and/or high-loss cases, this is highly beneficial.
This specification is different to, and incompatible with, XMPP over QUIC (XEP-0467)
Implementers are advised to note the Security Considerations of RFC 9000
This document requires no interaction with IANA.
This document requires no interaction with the XMPP Registrar
Open Question: Should it create a registry for stream types, though?