8 Feb
2026
8 Feb
'26
6: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