- Standards

Scoping discussion: updating XMPP RFCs / XMPP 2.0

by Guus der Kinderen

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

1 month, 2 weeks

7
8
0 0

Proposed XMPP Extension: Message Archive Management: Trim Command

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Message Archive Management: Trim Command Abstract: This specification describes how a client can request "trimming" of an archive URL: https://xmpp.org/extensions/inbox/xep-mam-trimming.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 month, 2 weeks

1
0
0 0

NEW: XEP-0513 (Explicit Mentions)

by Daniel Gultsch

Version 0.1.0 of XEP-0513 (Explicit Mentions) has been released. Abstract: This specification defines a way to explicitly mention a person or groups of people. Changelog: Accepted as Experimental by council vote on 2026-03-31 (dg) URL: https://xmpp.org/extensions/xep-0513.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 month, 2 weeks

1
0
0 0

NEW: XEP-0512 (XMPP as Interpretive Dance)

by Daniel Gultsch

Version 5.6.7.8 of XEP-0512 (XMPP as Interpretive Dance) has been released. Abstract: This document defines a method for representing XMPP communications through the medium of interpretive dance. By mapping core protocol elements to specific physical movements, it allows expressive, low- bandwidth, and audience-friendly implementations of XMPP suitable for artistic performances, theatrical demonstrations, and deeply confusing hackathons. Changelog: Initial published version. (gdk) URL: https://xmpp.org/extensions/xep-0512.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 month, 2 weeks

1
0
0 0

Extending XEP-0313 with trimming support

by Matthew Wild

Hi folks, There are a few limitations with XEP-0313 which I've been hoping to address for a while, mostly around giving users more control and making it easier for operators to comply with various data protection requirements. Users have control over most account data in XMPP. However archives are, generally, read-only. In particular, user data should generally be deleted upon request. Currently such requests would have to be manually sent to the service operator, as there is no in-band method for this yet. My proposal is to support an in-band 'trim' command, which allows removal of all archived messages, or up to (and including) a specific archived message, or deletion of the entire archive. The functionality is optional and discoverable, so shouldn't affect backwards compatibility. This has some limitations. For example, it wouldn't allow selectively deleting all messages with a specific contact, which is occasionally requested. Such an operation would leave holes in the archive (which XEP-0313 forbids to ensure sync points don't get removed). But I'm in favour of solving what we easily can for now. There are other things I would like to improve around archiving, such as exposing retention configuration. But I plan for these to live in new XEPs. As XEP-0313 is stable and almost universally implemented, I wanted to raise awareness of this proposal and seek some consensus from the community before pushing it forward to Council. The PR can be found at https://github.com/xsf/xeps/pull/1514 The new section is rendered at https://matthewwild.co.uk/uploads/xep-0313.html#trim Regards, Matthew

1 month, 2 weeks

4
9
0 0

XMPP Council Agenda 2026-03-31

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, March 31 2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join Notice the time zone change. For some people this might now be an hour later than usual. The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update • LAST CALL: XEP-0377 (Blocking Command Reports) • UPDATED: XEP-0461 (Message Replies) • UPDATED: XEP-0493 (OAuth Client Login) The two updated XEPs are just minor editorial changes. 4) Items for voting a) XEP-0045: Add clarification regarding unsetting reserved nicknames https://github.com/xsf/xeps/pull/1512 5) Pending votes Marvin, Stephan Paul, Dan, Jerome on XEP-xxxx: Explicit Mentions (https://xmpp.org/extensions/inbox/explicit-mentions.html) See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh… 6) Date of Next 7) AOB 8) Close

1 month, 2 weeks

1
0
0 0

UPDATED: XEP-0493 (OAuth Client Login)

by Daniel Gultsch

Version 0.1.1 of XEP-0493 (OAuth Client Login) has been released. Abstract: This specification details how a third-party can be securely granted access to an XMPP account without exposing the account credentials, using OAuth. Changelog: * Fix reference to RFC 7628 for SASL OAUTHBEARER (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0493.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 month, 2 weeks

1
0
0 0

UPDATED: XEP-0461 (Message Replies)

by Daniel Gultsch

Version 0.2.1 of XEP-0461 (Message Replies) has been released. Abstract: This document defines a way to indicate that a message is a reply to a previous message. Changelog: Update the example to use the correct fallback namespace. (mye) URL: https://xmpp.org/extensions/xep-0461.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 month, 2 weeks

1
0
0 0

LAST CALL: XEP-0377 (Blocking Command Reports)

by Daniel Gultsch

This message constitutes notice of a Last Call for comments on XEP-0377. Title: Blocking Command Reports Abstract: This document specifies a mechanism by which reporting information can be attached to a Blocking Command (XEP-0191) request. It enables servers to process reports related to blocked entities while remaining focused on this specific workflow rather than general abuse reporting. URL: https://xmpp.org/extensions/xep-0377.html This Last Call begins today and shall end at the close of business on 2026-04-14. 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!

1 month, 2 weeks

1
0
0 0

Problems with latest XEP-0377 updates

by Matthew Wild

Hi, Today I read through the latest revisions of XEP-0377, and a number of things stood out. I've broken this email into a section per issue. Namespace versioning -------------------------- Version 0.4.0 of XEP-0377 contains schema changes without changing the namespace. This contravenes XEP-0053, which states: "While the XEP is in the Experimental state, if appropriate and in consultation with the author(s), the XMPP Registrar shall update the namespace version number at the end of namespace (e.g., from "0" to "1"); the XMPP Registrar shall do so only if the protocol defined in the XEP has been modified in a way that is not backwards-compatible with an earlier version of the protocol." Generally, adding previously undefined elements is considered to be a breaking change that requires a new namespace, especially in a protocol that is already deployed. Possible remedies: Given that the current namespace is already implemented and deployed, I would have preferred to see this XEP advanced than modified. However, if there is consensus that we really need these new rules, they could be tacked on in a new namespace such as 'urn:xmpp:reporting:1#processing'. There is precedent for this approach in other XEPs, including XEP-0313. Failing that, we would have to update to 'urn:xmpp:reporting:2' and update all implementations (and this also is the only way to guarantee that implementations will honour the processing rules). Extensibility via elements ------------------------ The new version created a registry to allow new processing options to be defined. However it does this via elements. For the reasons above, this simply can't work - the schema would have to be updated every time a new processing rule is added. Especially once the XEP is advanced, schemas simply don't change like this. They get coded into implementations, and implementations would be free to reject unexpected elements. Instead, a valid approach would be to define the rules as strings (URIs are a common choice, but not strictly required) and have these passed as attribute values or character data. For example: <processing xmlns='urn:xmpp:reporting:1#processing'> <allow>origin</allow> <allow>third-party</allow> </processing> Thoughts on processing rules in general ----------------------- I get why the processing rules were added. However I really think they are approaching the problem backwards. As a service operator, receiving a report that says "here is a problem, but I forbid you from doing anything about it" is a rather silly situation. It would almost be better to not receive the report at all. For a long time, this was why multiple client developers said they weren't interested in even implementing reporting - because nothing useful actually happened on the server side, so the reports were at best logged and at worst discarded. A better approach is to have the server tell the client what will/may happen to reports that are submitted (and then give the user the choice of whether to submit or not). In most online services this disclosure happens in the Terms of Service and/or Privacy Policy. It is then up to the implementation and service operator to decide what (and how much) to share from reports, when to share them, and with whom. Per various worldwide laws, these things should often already be disclosed, regardless of the protocol layer in use. Renaming ------------ This is a more minor point, but I had planned to reuse the reporting payload in protocols other than XEP-0191: Blocking Command, and this reuse was definitely on the table at the summit where the protocol was initially discussed. I think the new title feels like it is discouraging such reuse, compared to the previous title and contents (where usage within XEP-0191 was provided as an initial location where reports should happen). I intend to submit protoXEPs based on this specification with or without any of the points in this email being addressed, I only thought I should provide the feedback as I saw the new changes and they surprised me. Regards, Matthew

1 month, 2 weeks

5
8
0 0

2026

2025

2024

2023

Standards