5 Feb
2026
5 Feb
'26
1:37 p.m.
Hi all,
At the recent Summit, we had a long and nuanced discussion about the state
of the XMPP RFCs and whether there is value in updating parts of them,
potentially through the IETF, to better reflect how XMPP is actually
implemented and used today.
To be clear upfront: This is not a proposal to start an IETF working group,
nor a commitment to produce new RFCs. The discussion at the Summit surfaced
enough open questions that it seems worthwhile to first have a focused
scoping and feasibility discussion.
Some of the motivations that were raised:
- The current RFCs do not describe a baseline that results in
interoperable modern implementations
- Discoverability for new implementers is difficult (knowing which XEPs
are "essential")
- The IM landscape has changed significantly since the original RFCs
- External review and feedback could be valuable
- There may be marketing and positioning benefits, but these are
secondary
At the same time, many concerns were raised:
- The sheer amount of work required, and whether we realistically have
the manpower
- Risk of scope creep (e.g., baking too much into RFCs)
- Loss of flexibility compared to the XEP process
- Fear of starting something we cannot finish
- Unclear interaction with compliance suites and the "living standard"
nature of XMPP
- Potential pushback or distraction from other IETF efforts (e.g., MIMI)
Questions that seem worth discussing at this stage:
- Is it useful to think about updating some RFCs (e.g., core, IM), while
leaving the rest to XEPs?
- What would be clearly in-scope vs out-of-scope?
- Is there enough interest and capacity to justify exploring this
further?
- What would be a sensible first step that does not overcommit us?
If you were at the Summit and felt strongly one way or the other, it would
be great to hear your perspective here. If you weren't, fresh viewpoints
are equally welcome.
The goal of this thread is simply to assess whether this topic is worth
pursuing further, and if so, in what very limited and realistic form.
Kind regards,
Guus
5 Feb
5 Feb
3:48 p.m.
I don't recall whether it was on the Summit floor, or in a chat I had
afterwards, but I recall some agreement that a good first step would be an
updated Compliance Suite which would give us an agreed starting point on
what an XMPP 2.0 might look like.
Dan
On Thu, 5 Feb 2026 at 18:38, Guus der Kinderen <guus.der.kinderen(a)gmail.com>
wrote:
Hi all,
At the recent Summit, we had a long and nuanced discussion about the state
of the XMPP RFCs and whether there is value in updating parts of them,
potentially through the IETF, to better reflect how XMPP is actually
implemented and used today.
To be clear upfront: This is not a proposal to start an IETF working
group, nor a commitment to produce new RFCs. The discussion at the Summit
surfaced enough open questions that it seems worthwhile to first have a
focused scoping and feasibility discussion.
Some of the motivations that were raised:
- The current RFCs do not describe a baseline that results in
interoperable modern implementations
- Discoverability for new implementers is difficult (knowing which
XEPs are "essential")
- The IM landscape has changed significantly since the original RFCs
- External review and feedback could be valuable
- There may be marketing and positioning benefits, but these are
secondary
At the same time, many concerns were raised:
- The sheer amount of work required, and whether we realistically have
the manpower
- Risk of scope creep (e.g., baking too much into RFCs)
- Loss of flexibility compared to the XEP process
- Fear of starting something we cannot finish
- Unclear interaction with compliance suites and the "living standard"
nature of XMPP
- Potential pushback or distraction from other IETF efforts (e.g.,
MIMI)
Questions that seem worth discussing at this stage:
- Is it useful to think about updating some RFCs (e.g., core, IM),
while leaving the rest to XEPs?
- What would be clearly in-scope vs out-of-scope?
- Is there enough interest and capacity to justify exploring this
further?
- What would be a sensible first step that does not overcommit us?
If you were at the Summit and felt strongly one way or the other, it would
be great to hear your perspective here. If you weren't, fresh viewpoints
are equally welcome.
The goal of this thread is simply to assess whether this topic is worth
pursuing further, and if so, in what very limited and realistic form.
Kind regards,
Guus
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
8 Feb
8 Feb
8:33 a.m.
On 2/5/26 11:37 AM, Guus der Kinderen wrote:
Hi all,
At the recent Summit, we had a long and nuanced discussion about the
state of the XMPP RFCs and whether there is value in updating parts of
them,
We've already done this to some extent (e.g., SASL2).
potentially through the IETF,
IMHO, the IETF is the ideal (and perhaps only) place to make changes to
the core and IM specs. If the XSF wanted to take back maintenance of
core and IM, we'd need to talk with our IETF friends.
to better reflect how XMPP is
actually implemented and used today.
To be clear upfront: This is not a proposal to start an IETF working
group, nor a commitment to produce new RFCs.
It's not clear to me yet whether we'd need a WG in order to do this
work. That might depend on the scope of changes and it's something we'd
need to discuss with the relevant IETF area directors.
The discussion at the
Summit surfaced enough open questions that it seems worthwhile to first
have a focused scoping and feasibility discussion.
Some of the motivations that were raised:
* The current RFCs do not describe a baseline that results in
interoperable modern implementations
* Discoverability for new implementers is difficult (knowing which
XEPs are "essential")
* The IM landscape has changed significantly since the original RFCs
* External review and feedback could be valuable
Those are all good reasons to do such work at the IETF.
* There may be marketing and positioning benefits,
but these are secondary
Although they are indeed secondary, we should recognize that those
benefits were one reason we moved the core/IM specs from the JSF to the
IETF in 2002 and 2003. The benefits included the ability for companies
building Jabber servers (at that time primarily Jabber Inc., which drove
the standardization effort) to better market their products to "serious"
customers like governments and large corporations. So this is still
something to consider, I think. Would moving all protocol development
(even core/IM) from the IETF to the XSF remove an important selling
point for XMPP vendors?
At the same time, many concerns were raised:
* The sheer amount of work required, and whether we realistically have
the manpower
I estimate that I worked 2000+ hours on RFCs 3920/3921 in 2003 and 2004.
The workload was less significant when revising 3920/3921 to produce
6120/6121, but I didn't measure it very carefully.
* Risk of scope creep (e.g., baking too much into
RFCs)
This is something we can manage. IMHO one of the goals would be to
create a minimal spec or set of specs for core and IM, thus avoiding
scope creep.
* Loss of flexibility compared to the XEP process
That's why we're having this discussion now, I suppose - doing the work
on core and IM through the IETF has led us to a place where it's not
easy to change those specs. That's one of the costs of handing change
control over to the IETF. On the other hand, the fact that it's taken us
20+ years to feel this pain might indicate that the tradeoffs were worth
making at that time (I still recall the concerns that DJ Adams and
others had about IETF standardization and loss of control). However, at
this point we have just enough institutional memory that we can
contemplate a renewed IETF initiative. That won't always be the case, so
maybe now is the time to try it.
* Fear of starting something we cannot finish
This is a legitimate concern - some IETF WGs run out of energy and it's
not pretty (I had to shut down a few WGs like that when I was an area
director).
* Unclear interaction with compliance suites and the
"living standard"
nature of XMPP
* Potential pushback or distraction from other IETF efforts (e.g., MIMI)
This is part of the discussion with the IETF. In general, if we can
demonstrate that we have enough people who want to do this work, then it
shouldn't be a distraction from MIMI or other current initiatives. Even
more explicitly, at the IETF such an objection is not taken seriously.
This is why we were able to form the XMPP WG even though the SIMPLE WG
was already in existence.
Questions that seem worth discussing at this stage:
* Is it useful to think about updating some RFCs (e.g., core, IM),
while leaving the rest to XEPs?
Yes.
* What would be clearly in-scope vs out-of-scope?
I'm too far away from current work to have clear thoughts on this. But I
would recommend creating a stripped-down spec that includes as few
features as possible, so that going forward it's easier to work on
extensions at the XSF.
* Is there enough interest and capacity to justify
exploring this further?
Maybe?
If it's helpful, I would consider coming out of retirement to assist
with this work.
* What would be a sensible first step that does not
overcommit us?
I see a few things:
1. Identify the scope of work. This is useful whether we do the work at
the IETF or negotiate with the IETF to take back maintenance of core and IM.
2. Identify who has the time and energy to work on the specs, provide
feedback on the specs, and implement the specs.
3. Have an initial, exploratory conversation with the relevant IETF area
directors.
Peter
9 Feb
9 Feb
7:36 p.m.
On February 5, 2026 1:37:28 PM EST, Guus der Kinderen <guus.der.kinderen(a)gmail.com>
wrote:
Hi all,
o/
Some of the motivations that were raised:
- The current RFCs do not describe a baseline that results in
interoperable modern implementations
- Discoverability for new implementers is difficult (knowing which XEPs
are "essential")
- The IM landscape has changed significantly since the original RFCs
Fully agree, but all of these can be solved in the XSF.
- External review and feedback could be valuable
Maybe, but no guarantee we'd get any, and anyone interested could already give this?
- There may be marketing and positioning benefits,
but these are secondary
I'd argue these don't exist at all. Look at the competitors in the space, where
they are being used, and not only a total lack of RFCs but not even an open standards org
like the XSF. No users or potential users care. at. all.
Kind regards,
Guus
Thanks!
moparisthebest
31 Mar
31 Mar
4:31 a.m.
Hi,
I just wanted to give a short update on my position on this subject.
Marvin and I were at IETF125 in Shenzen last week and independently of
each other had very positive interactions with key people in the IETF.
Generally speaking the vibe was very positive and welcoming. The fact
that XMPP already is an RFC and we are 'just' updating it means that
the process of (re)establishing a working group should not be a big
deal.
Process wise our first step would be to produce a draft to demonstrate
that there is something substantial.
What I had pitched to people at the IETF - and which I believe sort of
reflects what I’m hearing from our community is to first update core.
I mean the way you connect to an XMPP server these days looks
fundamentally different to what we have in 6120. (I think if and how
we also want to update IM and/or what extensions should be combined in
that RFC is something we don’t need to worry about at this point in
time.)
What I've been told repeatably is that we would be giving up change
control - but we know that. By extensions this obviously means that we
also have to be willing to update our respective implementations to
what ever comes out the other end of the IETF process. I think this is
fine? But if major XMPP implementers stay on the XSF flavor that would
be bad. (I realize that nobody can make any promises but a general
vibe check in our community on whether or not people would be willing
to implement the RFC version - independently of whether they have
worked on the RFC - would probably be good to do.)
The other thing someone mentioned to me - not as discouragement or as
a show stopper - but as a friendly tip - was that if we don’t get
outside collaborators / new participants and if instead it's only XSF
people working on it anyway then why bother? Marvin and I have plans
to organize a side meeting at the next IETF to maybe gauge some
interest. I think generally speaking there must be some interest in
the IETF community for standardized, federated instant messaging.
Matrix isn’t it. MIMI isn’t it. So there is currently a gap that XMPP
can fil. But maybe a side meeting in Vienna can help to figure out who
else is out there.
Speaking of IETF126 in Vienna: The IETF has a Hackathon on the
Saturday and Sunday (July 18th and 19th) that is free to attend and
even has free catering. Given the proximity of a lot of XMPP developer
to Vienna I think it would be nice if a few of us could attend there
to work on XMPP. (Even those that are not usually attending IETF). On
one hand it would be a nice opportunity to have a regular XMPP sprint
with the location and the food sorted for us. On the other hand
suddenly having an entire table full of XMPP people at an IETF event
will certainly raise some attention. At the end of the Hackathon there
is a 90s-2 minute opportunity to present the Hackathon project and I
did a presentation at the Hackathon in Shenzhen and apparently that
turned some heads as well. If we want people to notice XMPP that's a
good starting point. IETF126 Hackathon would be a win-win. Free
location free food for a sprint we regularly do anyway. + Maybe some
free advertisements (and raise attention for the side meeting we are
also trying to do)
cheers
Daniel
1 Apr
1 Apr
7:50 a.m.
Hi Daniel,
Thanks for the report, and to you and Marvin for travelling all the way
to Shenzen (!) for IETF 125.
Your suggestion of a hackfest at IETF 126 in Vienna is a great idea,
since it will introduce more people to folks active at the IETF and how
the IETF works.
As to change control, if it's managed correctly the IETF standardization
process should not result in arbitrary changes. "We believe in rough
consensus and running code" implies that if the code is running and
someone asks for changes that are merely aesthetic or their personal
preference, there's no good reason to make those changes (after of
course reasonably considering the concerns that have been raised).
As to "bring in new people", I think that's a bit of a red herring.
There is no such thing as "XSF people" or "IETF people" - there are
just
people. If some people come to the IETF asking to do some work
(especially if they are are *coming back* in good faith to update a
technology of long standing at the IETF), there is no requirement to get
new people interested. In my various roles at the IETF I have seen this
repeatedly with work on technologies like FTP.
As to "align this work with the need for a common messaging standard",
that could be a rat hole of epic proportions, so we'd need to understand
what kind of scope people are thinking about. Although I have no doubt
that there are ecosystem gaps XMPP can fill (and arguably should have
filled long ago), quite possibly those gaps have come about because of
product and (roughly speaking) political decisions made by the major
players, which can't necessarily be solved by a standardization effort,
especially one to update XMPP Core rather than define new extensions or
applications of XMPP. If some of the requirements align that's great,
but I'd be careful about saddling the update effort with a whole bunch
of new requirements just to satisfy the longing for a common messaging
standard, which has existed for 30 years and might never be satisfied.
Just my two cents, of course.
Peter
On 3/31/26 2:31 AM, Daniel Gultsch wrote:
Hi,
I just wanted to give a short update on my position on this subject.
Marvin and I were at IETF125 in Shenzen last week and independently of
each other had very positive interactions with key people in the IETF.
Generally speaking the vibe was very positive and welcoming. The fact
that XMPP already is an RFC and we are 'just' updating it means that
the process of (re)establishing a working group should not be a big
deal.
Process wise our first step would be to produce a draft to demonstrate
that there is something substantial.
What I had pitched to people at the IETF - and which I believe sort of
reflects what I’m hearing from our community is to first update core.
I mean the way you connect to an XMPP server these days looks
fundamentally different to what we have in 6120. (I think if and how
we also want to update IM and/or what extensions should be combined in
that RFC is something we don’t need to worry about at this point in
time.)
What I've been told repeatably is that we would be giving up change
control - but we know that. By extensions this obviously means that we
also have to be willing to update our respective implementations to
what ever comes out the other end of the IETF process. I think this is
fine? But if major XMPP implementers stay on the XSF flavor that would
be bad. (I realize that nobody can make any promises but a general
vibe check in our community on whether or not people would be willing
to implement the RFC version - independently of whether they have
worked on the RFC - would probably be good to do.)
The other thing someone mentioned to me - not as discouragement or as
a show stopper - but as a friendly tip - was that if we don’t get
outside collaborators / new participants and if instead it's only XSF
people working on it anyway then why bother? Marvin and I have plans
to organize a side meeting at the next IETF to maybe gauge some
interest. I think generally speaking there must be some interest in
the IETF community for standardized, federated instant messaging.
Matrix isn’t it. MIMI isn’t it. So there is currently a gap that XMPP
can fil. But maybe a side meeting in Vienna can help to figure out who
else is out there.
Speaking of IETF126 in Vienna: The IETF has a Hackathon on the
Saturday and Sunday (July 18th and 19th) that is free to attend and
even has free catering. Given the proximity of a lot of XMPP developer
to Vienna I think it would be nice if a few of us could attend there
to work on XMPP. (Even those that are not usually attending IETF). On
one hand it would be a nice opportunity to have a regular XMPP sprint
with the location and the food sorted for us. On the other hand
suddenly having an entire table full of XMPP people at an IETF event
will certainly raise some attention. At the end of the Hackathon there
is a 90s-2 minute opportunity to present the Hackathon project and I
did a presentation at the Hackathon in Shenzhen and apparently that
turned some heads as well. If we want people to notice XMPP that's a
good starting point. IETF126 Hackathon would be a win-win. Free
location free food for a sprint we regularly do anyway. + Maybe some
free advertisements (and raise attention for the side meeting we are
also trying to do)
cheers
Daniel
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
8:16 a.m.
Hi Peter,
On Wed, Apr 1, 2026 at 1:50 PM Peter Saint-Andre <stpeter(a)stpeter.im> wrote:
As to "bring in new people", I think
that's a bit of a red herring.
There is no such thing as "XSF people" or "IETF people" - there are
just
people. If some people come to the IETF asking to do some work
(especially if they are are *coming back* in good faith to update a
technology of long standing at the IETF), there is no requirement to get
new people interested. In my various roles at the IETF I have seen this
repeatedly with work on technologies like FTP.
As to "align this work with the need for a common messaging standard",
that could be a rat hole of epic proportions, so we'd need to understand
what kind of scope people are thinking about. Although I have no doubt
that there are ecosystem gaps XMPP can fill (and arguably should have
filled long ago), quite possibly those gaps have come about because of
product and (roughly speaking) political decisions made by the major
players, which can't necessarily be solved by a standardization effort,
especially one to update XMPP Core rather than define new extensions or
applications of XMPP. If some of the requirements align that's great,
but I'd be careful about saddling the update effort with a whole bunch
of new requirements just to satisfy the longing for a common messaging
standard, which has existed for 30 years and might never be satisfied.
thank you very much for you input.
I’m thinking about all this as a medium to long term project. I think
we have a rough direction but we don’t know exactly where we are
going. I believe that even without widening the scope - purely with
what we have right now - we can provide value to other players as
well. One thing I’m increasingly getting aware of after talking to
people inside and outside the IETF is that many people just aren’t
aware of what we have.
That’s what I’m trying to have the side meeting for. Making people
aware of what we have and finding out if people are interested in
that.
But, yes - again - everything you say on scope creep is well noted.
cheers
Daniel
5:07 p.m.
Am Mittwoch, 1. April 2026, 15:52:16 CEST schrieb Stephen Paul Weber:
Yes, SASL2, BIND2 and you could argue that to some degree stream resumption
and MAM are part of "connect to the server" as well.
-tmolitor
I mean the way
you connect to an XMPP server these days looks
fundamentally different to what we have in 6120.
You mean if using SASL2?
23
days inactive
78
days old
8 comments
7 participants
participants (7)
-
Dan Caseley -
Daniel Gultsch -
Guus der Kinderen -
Peter Saint-Andre -
Stephen Paul Weber -
Thilo Molitor -
Travis Burtrum