June 2026 - Standards

We should require AI disclosure
by Goffi 09 Oct '26

09 Oct '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 43

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

NEW: XEP-0516 (XMPP Decentralized ID (XID))
by Daniel Gultsch 01 Jul '26

01 Jul '26

Version 0.1.0 of XEP-0516 (XMPP Decentralized ID (XID)) has been released. Abstract: XMPP Decentralized ID (XID) is a DNS independent XMPP entity identifier. This specification describes how to generate, use, and handle them. Changelog: Accepted as Experimental by council vote (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0516.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

3 2

Jingle user location
by Edward Tie 01 Jul '26

01 Jul '26

|Thank you for the feedback. Could you please clarify the main objection to the Jingle User Location proposal? I would like to understand what should be changed before revising it. Is the objection about the use of Jingle, the relation to XEP-0080, privacy/consent, emergency-use wording, scope, or something else? I do not want to assume the reason. If you can point to the specific part that is problematic, I can make the next revision more focused.| greetings, Edward Tie .

1 0

NEW: XEP-0517 (Jingle Synchronized Real-Time Text)
by Daniel Gultsch 01 Jul '26

01 Jul '26

Version 0.1.0 of XEP-0517 (Jingle Synchronized Real-Time Text) has been released. Abstract: This specification defines a Jingle application extension for negotiating real-time text as part of the same conversational session as audio and video. Changelog: Accepted as Experimental by council vote (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0517.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

XMPP Council Agenda 2026-06-30
by Daniel Gultsch 30 Jun '26

30 Jun '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, June 30 2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update • UPDATED: XEP-0420 (Stanza Content Encryption • UPDATED: XEP-0514 (Emoji Markup) • NEW: XEP-0515 (TLS Channel-Binding Downgrade Protection) 4) Items for voting a) Proposed XMPP Extension: Payment Required https://xmpp.org/extensions/inbox/payment-required.html 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh… 6) Date of Next 7) AOB 8) Close

1 0

NEW: XEP-0515 (TLS Channel-Binding Downgrade Protection)
by Daniel Gultsch 30 Jun '26

30 Jun '26

Version 0.1.0 of XEP-0515 (TLS Channel-Binding Downgrade Protection) has been released. Abstract: This specification provides a way to secure the SASL and SASL2 SCRAM handshakes against channel-binding downgrades through TLS version downgrades. Changelog: Accepted as Experimental by council vote (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0515.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

UPDATED: XEP-0514 (Emoji Markup)
by Daniel Gultsch 30 Jun '26

30 Jun '26

Version 0.1.1 of XEP-0514 (Emoji Markup) has been released. Abstract: This specification leverages Message Markup (XEP-0394) and Stateless file sharing (XEP-0447) (or Stateless Inline Media Sharing (XEP-0385)) to send custom emojis Changelog: Remove outdated reference to BoB (techmetx11) URL: https://xmpp.org/extensions/xep-0514.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

UPDATED: XEP-0420 (Stanza Content Encryption)
by Daniel Gultsch 30 Jun '26

30 Jun '26

Version 0.5.0 of XEP-0420 (Stanza Content Encryption) has been released. Abstract: The Stanza Content Encryption (SCE) protocol is intended as a way to allow clients to securely exchange arbitrary extension elements using different end-to-end encryption schemes. Changelog: The time affix uses the DateTime profile of XEP-0082 Longer rpads MUST NOT be rejected Add a minimum size target for random padding to add resistance against potential correlation attacks in case of short content and 0-length rpad Removed unhelpful Implementation Note warning about injection of decrypted stanzas Clarify fallback body policy Fix descriptions to apply to all stanzas instead of just messages Remove questionable SHOULD in the time affix handling and clarify the affix'es verification Request the registrar to provide a list of exclusively server- processed elements List XEP dependencies Add XML schema (syndace) URL: https://xmpp.org/extensions/xep-0420.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

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

30 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