May 2026 - Standards

We should require AI disclosure
by Goffi 14 Jul '26

14 Jul '26

Hello everybody, I would like to bring a discussion on AI policy. We can't really ignore anymore that modern models have become very capable, and I suspect that they are used for spec authoring. This raises, I believe, copyright issues: if someone use AI to redact a whole section of a spec, how can we be sure that it's not an existing specs for some other place, possibly under copyright, that is copied or paraphrased? How can an author guarantee that it's original work (hint: they can't)? I think that there are 3 distinct uses: 1. As a light formatting/checking help, for instance to generate a table from a human written section, to correct the formulation of a sentence, or to draft an example. This is notably useful for non native English speakers. 2. As a help to search existing state of art on some feature, or any kind of data, without writing anything in a protoXEP. 3. As a way to generate whole sections. Instinctively, and If we put aside ethical and ecological concerns about LLMs, I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases, it should be disclosed. I would like your feedback on this matter, in particular people with legal knowledge. I would like to avoid a flamewar, I know that this topic is sensitive and there opinions are highly divided, please express your opinion calmly. The fact is, we can't ignore this anymore. Should this be discussed with board or council? Thanks. Best, Goffi

14 42

LAST CALL: XEP-0424 (Message Retraction)
by Daniel Gultsch 03 Jul '26

03 Jul '26

This message constitutes notice of a Last Call for comments on XEP-0424. Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted. URL: https://xmpp.org/extensions/xep-0424.html This Last Call begins today and shall end at the close of business on 2025-01-06. Please consider the following questions during this Last Call and send your feedback to the standards(a)xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!

9 27

Scoping discussion: updating XMPP RFCs / XMPP 2.0
by Guus der Kinderen 29 Jun '26

29 Jun '26

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

7 9

draft-ietf-kitten-sasl-ht-01 uploaded
by Florian Schmaus 22 Jun '26

22 Jun '26

[cc to standards(a)xmpp.org since it is of interest to the xmpp ecosystem] I've uploaded draft-ietf-kitten-sasl-ht-01. The major changes since the adoption by the Kitten WG are - the introduction of a response status byte to indicate success or failure responses - the capability to transmit authenticated key/value pairs in the exchanged messages (e.g., for XEP-0474 [1]) SASL-HT is already deployed using an older and incompatible version of the I-D in some parts of the XMPP ecosystem. Therefore, we probably need to adjust the SASL Mechanism Name to avoid interoperability issues. For example, from HT-SHA-512-ENDP to HT2-SHA-512-ENDP Please forgive my lack of creativity regarding the new name. Suggestions on a more creative naming schema that is in-line with the constraints of SASL Mechanism names are appreciated. And, of course, feedback in general is welcomed. - Florian 1: https://xmpp.org/extensions/xep-0474.html

5 5

Proposal: Add <no-notify/> hint to XEP-0334 (Message Processing Hints)
by Laura G. 22 Jun '26

22 Jun '26

I'd like to propose adding a new processing hint to XEP-0334 to support silent/whisper messages - messages that are delivered normally but don't trigger notifications on the recipient's device. Use Case: My mother and I communicate via XMPP throughout the day. She frequently participates in screen recordings and video calls (about 1 hour daily) where notification sounds and popups would be disruptive. However, she doesn't want to use DND mode because she needs to remain reachable for genuine emergencies. The solution we need: the ability to send non-urgent messages silently so she can read them when she next checks her client, without interrupting her work. User Demand: This feature is heavily requested across messaging platforms. A quick search shows thousands of users asking "how to send silent messages" or "send without notification" for Facebook Messenger, WhatsApp, Telegram, and other platforms. Telegram already implements this as "send without sound." The demand is clear and widespread. Proposed Addition to XEP-0334: A <no-notify/> processing hint with the following semantics: <message to='recipient(a)example.com' type='chat'> <body>Please look at the following when you have time: ...</body> <no-notify xmlns='urn:xmpp:hints'/> </message> Behavior: - The receiving client SHOULD NOT trigger audio/visual notifications - The message SHOULD still be delivered and stored normally - The message SHOULD appear in the chat history - The message MAY still update unread counts (implementation-dependent) - Clients MAY provide UI indication that a message was sent silently Benefits: - Allows nuanced communication without forcing binary DND states - Respects recipient's focus/workflow while maintaining async communication - Reduces notification fatigue - Provides sender control over message urgency - Simple to implement - clients already have notification suppression logic Backwards Compatibility: Clients that don't recognize <no-notify/> will simply deliver the message normally, which is acceptable fallback behavior. This would be a natural extension to the existing hint types in XEP-0334 (no-store, no-copy, store, no-permanent-store) and addresses a genuine gap in XMPP's messaging capabilities. Thoughts? Is this something the community would support adding to XEP-0334, or would it be better suited as a separate XEP? Best regards, L.G. I'm using an email mask just because I don't want recruiters to get a view of my personal life, please consider the proposal objectively.

6 8

Proposed XMPP Extension: Payment Required
by Daniel Gultsch 15 Jun '26

15 Jun '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Payment Required Abstract: This specification defines an XMPP protocol extension that enables services to require payment before granting access to a resource. It provides a payment-system neutral invoice format supporting multiple concurrent payment options, including bank transfers (SEPA, IBAN, UPI) and instant-settlement networks (Lightning Network), and integrates with the existing CAPTCHA challenge mechanism defined in XEP-0158. URL: https://xmpp.org/extensions/inbox/payment-required.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

8 11

Fw: [Members] [Vote] London XMPP Sprint 2026
by Polarian 28 May '26

28 May '26

Apologies, I sent this to the members mailing list however some developers are not members. Please vote on the dates which work best for you. It will be a 3 day sprint. Venue is currently not decided, but will be somewhere in London :) Begin forwarded message: Date: Sun, 17 May 2026 16:15:06 +0100 From: Polarian via Members <members(a)xmpp.org> To: members(a)xmpp.org Cc: Polarian <polarian(a)polarian.dev> Subject: [Members] [Vote] London XMPP Sprint 2026 Good afternoon, After discussions with Matthew yesterday, we have decided that the sprint should be held on one of the following ranges of dates. * Fri 25th Sep to Sun 27th Sep * Fri 2nd Oct to Sun 4th Oct * Fri 9th Oct to Sun 11th Oct * Fri 16th Oct to Sun 18th Oct * Fri 23th Oct to Sun 25th Oct * Fri 30th Oct to Sun 1st Nov * Fri 6th Nov to Sun 8th Nov * Fri 13th Nov to Sun 15th Nov * Fri 20th Nov to Sun 22nd Nov * Fri 27th Nov to Sun 29th Nov To vote, please copy the above list, and reply WITHIN THE THREAD to me either privately (if you don't want it public) or onlist and put one of the following symbols next to every range: + (Available) x (Unavailable) - (Could be available) For those who are not able to post to the list, please send me an email (polarian(a)polarian.dev) and I will include your vote, please only vote if you are interested in attending. I will count the responses and pass them onto Matthew on Sunday 24th May (1 week from now). Note: Matthew is *NOT* MattJ aka Matthew Wild, we really need to find a solution to the duplicate Matthews. Happy voting! Take care, -- Polarian Jabber/XMPP: polarian(a)icebound.dev -- Polarian Jabber/XMPP: polarian(a)icebound.dev

2 4

XSF Process Change Proposals
by Dave Cridland 15 May '26

15 May '26

Hi all, Apologies for this being long. Recent conversations have left me with two distinct impressions: 1) Some people within the XSF have a very different idea of what our process is than I do, that in my view does not match what we have documented. 2) A significant number of those that do share my understanding of the process (and presumably all of those that don't) wish it were different. Frankly, whether I agree with the second group is broadly immaterial - if the consensus is that our process isn't currently what we want it to be, we should change it to something that does have consensus. This message is to try to come up with a set of proposals which can gain consensus, while not totally rewriting the process. As I've noted several times before, I hugely dislike process, and documenting it, but I hate having a documented process that doesn't match what we do (or want to do) even more. I cannot begin to describe how hugely frustrating it is to enter the process in good faith only to discover that's not the process people will enforce. And I'm an old hand, for newcomers it must be even worse. So it's probably time to wade into XEP-0001 once again. I do not have any special rights over XEP-0001, I'm not on the Board or Council, and while I'm an XSF Member that gives no authority over anyone else in the Standards SIG (ie, this list, basically). So anything I say or suggest herein should not be considered final or preferential in any way - you're all welcome (and encouraged) to debate it. So, with that out of the way, here's what I think the rough consensus of our red lines should be (noting I'm not using RFC 2119 language here!): Point A - All specification development should be as open and accessible as possible, operate within a well-documented process, and unequivocally within our IPR policy. Point B - As an organisation, progression along the lifecycle of XEPs should give clear and unambigious signals as to the maturity of the document. Point C - We don't want to dilute Experimental XEPs with "slop", for want of a better word. My impression from people is that there is a concern that because Experimental is very broad in terms of maturity levels it fails on Point B above. Experimental was, I believe, designed to be the rough equivalent to Internet-Drafts in the IETF, which have absolutely no standing, although the XSF "adopts" them as an IETF Working Group does. Over the years, we've introduced technical (and social) changes that mean that specifications in Experimental have become safer to implement and deploy. Proposed currently is a short-lived state that we often ignore - it's from Last Call up to Stable. This shouldn't last more than a couple of weeks, normally. There's no documented quality gate for entering it, though there is a Council vote - then a Last Call, then another Council vote. As such the signal prior to Stable is very fuzzy, so to tighten it up there are a few options. First, we could "left shift" - and I think this is what's been happening. By applying the requirements of Stable (and in some cases, Final) to Experimental, we push things off the beginning of the XSF's process. That, I feel very strongly, is wrong, since it violates Point A on all counts, and in any case leaves no benefit or point to Stable or Final. Second, we could try and refine Experimental. My proposal here - because I do have a concrete proposal - is to attempt to address Point B by making Experimental better defined, and expanding Proposed. Proposal 1 : For Experimental, I propose that XEP-0001 makes it clear that such documents are "works in progress" - it does this already - but also that they may contain errors and ommissions, and may prove unimplementable. This is not, in fact, a change from our current process. Proposal 2 : For Proposed, I suggest we expand this with the quality gate that we expect specifications be implementable, have strong interest from the relevant subsection of the community in implementing, and consensus that they address a problem. Specifications would then enter this as the "final straight" to Stable, have *multiple* Last Calls (I know) and then once the Author is satisfied a Council vote to advance to Stable (or Rejected, or leave it where it is in Proposed). I suggest also introducing a timer that after six months, if not advanced to Stable, they drop back to Experimental. In summary, then, Proposed becomes a strong candidate for Stable. I think this addresses Point B without damage to Point A - that is, Experimental XEPs are more formally "the wild west", and Proposed is "We're pretty sure this works and you should try it". I also think it raises the bar for Stable, which is either a good thing, or a high risk that means we don't have a use for Final. We might wish to note Stable is intended for widespread deployment, rather than mere implementation, and that it's feedback from this widespread deployment that might yet cause changes. I think these are wording changes to match reality, though. I anticipate that some specifications - mostly those that Council are currently accepting - will spend little time in Experimental, and rapidly move to Proposed. That seems like a good thing. Others will spend a lot of time in Experimental, developing. To address Point C, I noticed that in "the old days", we used to require 5% of membership to trigger Council votes, and while I don't wish to "bind" Council, this got me thinking down a line of increasing the signals available to Council. While I'm not worried, personally, about Point C, I do appreciate that others are, and I also note that "AI slop" in particular is a growing problem. Proposal 3 : I propose we introduce a new Call to the SIG (ie, Editor questionnaire sent to the list), which asks for Expressions Of Interest for submitted ProtoXEPs. This should give Council guidance on what documents the community actually wants to work on. XEP-0001 should provide guidance that Council should reject submissions without sufficient interest, and is ordinarily expected to follow the consensus of the SIG. (Which SIG is an interesting question; we normally only have one). I think in the past, and still now on occasion, we've treated the ProtoXEP announcements this way anyway. But formalizing this (and formalizing the idea we're looking for Expressions Of Interest) seems like a good way to gate slop nobody cares about. Presumably if people do care, it is by definition not slop? Proposal 4 : Further, I think it'd be useful to introduce additional guidance as to what is expected of a ProtoXEP submission. First, a new mandatory section of the Problem Statement, such that Council and the SIG a better idea of what the author is hoping to solve, and second, that the ProtoXEP should give a clear idea as to the general approach. This is aimed at explicitly allowing XEPs which are not fully formed, while still providing the kind of information that will let people (SIG and Council) avoid letting in entirely vague slop. Note that neither Proposals 3 or 4 place any limit on Council's veto, nor any recourse/appeal, though it does shift to providing some guidance and expectation. Ultimately, XSF Members just need to vote in sensible, trusted people who follow the process. Related to Proposal 3, there's also: Proposal 5 : Finally I propose we document the Call questionnaires that the Editor sends. This do form part of our process, and a significant part at that. I propose these are documented together in a new XEP, so that they're a little easier to change. Technically these would be Procedural and thus Board approved, but we have historically placed the mechanics of how XEP-0001 is implemented under Council control (see XEP-0143) and I'm inclined to continue that if Board agrees. I'm happy to commit to the time/effort to write these up (though Proposal 5 might be better done by the Editor), but I'd like to gauge interest from the community first, and adjust the proposals as needed to get the best consensus. Once again, apologies for the length, and thanks for reading this far. I owe you a drink, or something. As a final note, I don't think my MUC ProtoXEP would get published under these proposals - but I think I'd have a clearer idea on why - and how to fix it. Dave.

6 9

Fwd: Pilot project for standards participation
by Dave Cridland 14 May '26

14 May '26

Not an XSF thing, but there's a Standards programme going on at Soverign Tech that can fund open source maintainers to get to IETF (and other) meetings. It's aimed at those who cannot otherwise go, to bring new voices in. I've not been to an IETF week in a while, but they're truly fascinating, and I'd highly recommend it. If you're maintaining open source software and want to go, but can't afford to, then you've a few days left to sign up. This really is a great opportunity! ---------- Forwarded message --------- From: Ted Hardie <ted.ietf(a)gmail.com> Date: Thu, 14 May 2026 at 09:05 Subject: Re: Pilot project for standards participation To: IETF <ietf(a)ietf.org> I wanted to bump this both because the deadline is coming soon: 19 May 2026 at 11:59 PM and because there were a number of questions about whether folks could apply if they would be invoicing via an institution*. *There's an updated FAQ on that: https://www.sovereign.tech/programs/standards/faq. The key text is: "Generally, it is our strong preference to work directly with open source maintainers through this program, either as a freelance agreement or as a contract with a sole proprietor. We do recognize that open source maintainers operate in a variety of organizational settings. If you meet the requirements of the program <https://www.sovereign.tech/programs/standards#requirements> but can only invoice us through a legal entity that employs others, you are welcome to apply. Please bear in mind the following: - We may exclude applications for any reason at our sole discretion. As per our goal to bring missing and underrepresented voices into standards organizations, applications from organizations which do not require public support for this work are likely to be excluded. - The program is centered around building a relationship with individual maintainers. If an organization's relationship with the individual ends or changes in a manner impacting the work, Sovereign Tech Agency's relationship with the organization will also come to an end. - We will not be able to accommodate significant changes to our standard legal agreements, which we will ask strong applicants to review ahead of time." So if that was holding anyone back from applying, please consider whether the update changes your ability to take advantage of the opportunity. regards, Ted Hardie On Thu, May 7, 2026 at 1:49 PM Ted Hardie <ted.ietf(a)gmail.com> wrote: > I sent this information to the hackathon and open-source lists, but it was > suggested I share a bit more widely. > > Some time ago, the Sovereign Tech Agency run a survey on the ability of > open source maintainers to participate in standards work. Based on that > data, they have now developed a pilot project for supporting open source > maintainers that want to get involved with standards. That pilot has > launched, with the IETF as one of the targets (along with the W3C and > ISO). Background information is here: > > https://www.sovereign.tech/news/join-sovereign-tech-standards-network > > along with the application details: > > https://www.sovereign.tech/programs/standards > > Here's a direct link to the application as well: > > https://ats.talentadore.com/apply/sovereign-tech-standards/mXw0q0 > > If you know of open source folks who might be interested in this kind of > support, please share it with them. > > thanks, > > Ted Hardie > >

1 0

Proposed XMPP Extension: New MUC
by Daniel Gultsch 12 May '26

12 May '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: New MUC Abstract: This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045, but adds a number of key improvements. URL: https://xmpp.org/extensions/inbox/new-muc.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

6 26