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

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