August 2026 - Standards

XMPP Council Agenda 2026-08-25
by Daniel Gultsch 21 Oct '26

21 Oct '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 25 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-0066 (Out of Band Data) https://xmpp.org/extensions/xep-0066.html • UPDATED: XEP-0515 (TLS Channel-Binding Downgrade Protection) https://xmpp.org/extensions/xep-0515.html • NEW: XEP-0518 (Payment Required) https://xmpp.org/extensions/xep-0518.html 4) Items for voting a) XEP-0143: Add author responsibility to submission process https://github.com/xsf/xeps/pull/1552 b) XEP-0490: Add security consideration for sender verification of PEP notifications https://github.com/xsf/xeps/pull/1554 c) XEP-0134: Add guideline against context-dependent elements https://github.com/xsf/xeps/pull/1558 d) XEP-0084: Fix example with both pubsub and HTTP source https://github.com/xsf/xeps/pull/1559 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

4 4

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 21 Sep '26

21 Sep '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 2026-07-20. 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!

8 16

XEP-0388 xs:sequence in schema
by Dave Cridland 30 Aug '26

30 Aug '26

Hey folks, Travis pointed out a "bug" in ejabberd around the ordering of SASL2 elements, because XEP-0388 uses xs:sequence I suspect this isn't a bug in ejabberd, but a bug in XEP-0388 for using xs:sequence instead of xs:all - I suspect I wrote this and was just being rubbish at writing schemas, and didn't intend to impose an ordering, much less have receiving implementations depend on it. How much pain would it be to just change it? Dave.

2 1

XEP-0474: proposal to add more test vectors (verification needed first)
by Guus der Kinderen 28 Aug '26

28 Aug '26

Hi all, I've recently implemented XEP-0474 (SASL SCRAM Downgrade Protection, version 0.5.0) in Openfire. The example in section 6.3 was useful during that work. While writing tests I generated a handful of additional vectors, and I think the XEP would be more useful to implementers if it carried a few more of them. The cases I found worth pinning down: - the 6.3 example extended to SHA-256 and SHA-512, since the specification applies to any SCRAM hash function but only exemplifies one; - a case where no channel-binding types were advertised, which is where an implementation might wrongly emit a bare %x1F separator; - a case including non-SCRAM mechanisms (PLAIN, EXTERNAL), making it explicit that the full advertised mechanism list is hashed, not just the SCRAM ones; - the single-entry degenerate cases. In A and C the values are deliberately listed in an order that differs from the sorted order, so an implementation that skips the i;octet sort will fail those two. B, D and E instead pin down the presence or absence of the %x1F section. The vectors are below. I've given the hash input both as an escaped string and as hex, so that the list construction and the hashing can be checked separately. Important caveat: these come from a single implementation (mine). The SHA-1 value of the first one is the only one that is already published in the XEP. I would not want the others added to the specification on the basis of my implementation alone: A test vector that is wrong is worse than no test vector. So: would anyone with an independent XEP-0474 implementation be willing to check them? If more people arrive at the same values independently, I'm happy to write them up as a pull request against the XEP in whatever form the author and council prefer. If anyone arrives at different values, that is an even more interesting result - please let me know either way. -- A. The existing §6.3 example ------------------------------------------ advertised mechanisms : SCRAM-SHA-1, SCRAM-SHA-1-PLUS advertised cb types : tls-server-end-point, tls-exporter hash input : SCRAM-SHA-1%x1ESCRAM-SHA-1-PLUS%x1Ftls-exporter%x1Etls-server-end-point input (hex) : 534352414d2d5348412d311e534352414d2d5348412d312d504c55531f746c732d6578706f727465721e746c732d7365727665722d656e642d706f696e74 SHA-1 : G6k/rBLDqgOhRRaCuuatSDFkJ08= SHA-256 : H6VEQ+6wl/eYKuTjJn4D9/e9GTn1AcYGw/oiSJ3Yhy0= SHA-512 : Q1q0WwH927l2RRoYIMiDY0g7R21hTZK+bfBgkhqek9JSTfIzUlnUZQRB2A6lZL3ER7ZMWRRdQzEJKVH671Bh0g== -- B. Same mechanisms, no channel-binding advertised ---------------------- advertised mechanisms : SCRAM-SHA-1, SCRAM-SHA-1-PLUS advertised cb types : (none) hash input : SCRAM-SHA-1%x1ESCRAM-SHA-1-PLUS input (hex) : 534352414d2d5348412d311e534352414d2d5348412d312d504c5553 SHA-1 : g00gt4Qd0gJ3EvnclTnY0KEYfRg= SHA-256 : Uuua9QJnTss43LMyJpE0esh43d9r8DB6N89DXs91aFo= SHA-512 : eOeUdpE/0pNIUnVTIcURoWHTT22Ohgk8C5/03RZTyqK9vShp/jK5G+v7G36yqSEsZgXnH7wVq2gBuUxm11OEHA== -- C. Full advertisement, including non-SCRAM mechanisms ------------------ advertised mechanisms : SCRAM-SHA-1, SCRAM-SHA-1-PLUS, SCRAM-SHA-256, SCRAM-SHA-256-PLUS, PLAIN, EXTERNAL advertised cb types : tls-unique, tls-exporter, tls-server-end-point hash input : EXTERNAL%x1EPLAIN%x1ESCRAM-SHA-1%x1ESCRAM-SHA-1-PLUS%x1ESCRAM-SHA-256%x1ESCRAM-SHA-256-PLUS%x1Ftls-exporter%x1Etls-server-end-point%x1Etls-unique input (hex) : 45585445524e414c1e504c41494e1e534352414d2d5348412d311e534352414d2d5348412d312d504c55531e534352414d2d5348412d3235361e534352414d2d5348412d3235362d504c55531f746c732d6578706f727465721e746c732d7365727665722d656e642d706f696e741e746c732d756e69717565 SHA-1 : SQjUrwq125kFEHbaywmNGkNY8NI= SHA-256 : jl3RxAJC6h0xX0nWBprC7vAD09HBsUNvCx5Ei/97Lt4= SHA-512 : 8822jz/cRVDn3bk/XTx/RgrUHucqhcpcqWTOzXIU8lMwLZr2aKT/GXnqYdLWDLZS/qkmt7vmkPM7FJ0I8ADi2Q== -- D. Minimal: one mechanism, one channel-binding type -------------------- advertised mechanisms : SCRAM-SHA-256-PLUS advertised cb types : tls-exporter hash input : SCRAM-SHA-256-PLUS%x1Ftls-exporter input (hex) : 534352414d2d5348412d3235362d504c55531f746c732d6578706f72746572 SHA-1 : 50fovNdJS+nqcJ0IYUsXqRTUrtU= SHA-256 : vxAYBdhmEYs9EAv8GQJQqk2YPUoLPUaj9em9zXzXzA0= SHA-512 : Fk0ja0KqooAP1flikg4vmSejIFhTSExpY1qISx86+1xAgftZDqyAN0cokd2RWPt1ttQSYlxr2EA8BRj7jwLiow== -- E. Single mechanism, no channel-binding advertised --------------------- advertised mechanisms : SCRAM-SHA-1 advertised cb types : (none) hash input : SCRAM-SHA-1 input (hex) : 534352414d2d5348412d31 SHA-1 : LrtFoCs8XsoI+diY4u3rG69UGN8= SHA-256 : hzhrgAj6xgd4yQIejnb2tHGgllHiKhjRwvofy7ETi64= SHA-512 : EMrc8V7X7onzZnTj6wtLdWqN9CM6v3VhUIZ2Th01rCX/uSlNzKVafB2MBIriyBEjzGLGEjlnn1e8nI4LHR4rDQ== Kind regards, Guus

2 1

UPDATED: XEP-0490 (Message Displayed Synchronization)
by Daniel Gultsch 27 Aug '26

27 Aug '26

Version 1.1.0 of XEP-0490 (Message Displayed Synchronization) has been released. Abstract: This specification allows multiple clients of the same user to synchronize the displayed state of their chats. Changelog: * Add security consideration for sender verification of PEP notifications. (dg) URL: https://xmpp.org/extensions/xep-0490.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-0084 (User Avatar)
by Daniel Gultsch 27 Aug '26

27 Aug '26

Version 1.1.5 of XEP-0084 (User Avatar) has been released. Abstract: This document defines an XMPP protocol extension for exchanging user avatars, which are small images or icons associated with human users. The protocol specifies payload formats for both avatar metadata and the image data itself. The payload formats are typically transported using the personal eventing profile of XMPP publish-subscribe as specified in XEP-0163. Changelog: Fix inconsistent hash in the example with multiple data sources for the same file. (nc) URL: https://xmpp.org/extensions/xep-0084.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

NEW: XEP-0518 (Payment Required)
by Daniel Gultsch 25 Aug '26

25 Aug '26

Version 0.1.0 of XEP-0518 (Payment Required) has been released. 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 built on payment URIs (such as the RFC 8905 payto scheme), supporting multiple concurrent payment options, from bank transfers to transfers over distributed ledgers or instant-settlement networks, and integrates with the existing CAPTCHA challenge mechanism defined in XEP-0158. Changelog: Accepted as Experimental by council vote on 2026-07-07 (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0518.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-0515 (TLS Channel-Binding Downgrade Protection)
by Daniel Gultsch 25 Aug '26

25 Aug '26

Version 0.1.1 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: Fixed typo in Bind 2 namespace (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-0066 (Out of Band Data)
by Daniel Gultsch 25 Aug '26

25 Aug '26

Version 1.6 of XEP-0066 (Out of Band Data) has been released. Abstract: This specification defines two XMPP protocol extensions for communicating URIs, one for use in XMPP message stanzas and the other for use in a structured request-response interaction via XMPP IQ stanzas. Among other things, this enables one entity to inform another entity about a file that is available at an HTTP URL. Changelog: Twenty years later, strike section 6's SI suggestion (dwd) URL: https://xmpp.org/extensions/xep-0066.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