- Standards

LAST CALL: XEP-0424 (Message Retraction)

by Daniel Gultsch

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!

1 day, 1 hour

7
13
0 0

XMPP Summit 29 (Friday + Saturday)

by Daniel Gultsch

Hi all, the 29th XMPP Summit is coming up in a little over 24 hours. Friday and Saturday from 13:00-16:00 UTC. This is our first online summit and is hosted on a Big Blue Button server provided to us by the FSFE. https://conf.fsfe.org/b/mkw-hvi-ujx-kb7 This is your last chance to propose some topics on our wiki. https://wiki.xmpp.org/web/Conferences/Summit_29#Proposed_Topics We will be voting on the 4 topics that we are going to be discussing very early in our Friday time slot. So be on time and do get familiar with the topics beforehand. On time means 20 minutes early! The room will be open and we will be having some nice hallway discussions. cheers Daniel

3 days, 21 hours

1
0
0 0

XEP-0388 xs:sequence in schema

by Dave Cridland

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.

1 week, 1 day

2
1
0 0

XEP-0474: proposal to add more test vectors (verification needed first)

by Guus der Kinderen

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

1 week, 3 days

2
1
0 0

UPDATED: XEP-0490 (Message Displayed Synchronization)

by Daniel Gultsch

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 week, 4 days

1
0
0 0

UPDATED: XEP-0084 (User Avatar)

by Daniel Gultsch

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 week, 4 days

1
0
0 0

XMPP Council Agenda 2026-08-25

by Daniel Gultsch

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

1 week, 5 days

3
3
0 0

NEW: XEP-0518 (Payment Required)

by Daniel Gultsch

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 week, 6 days

1
0
0 0

UPDATED: XEP-0515 (TLS Channel-Binding Downgrade Protection)

by Daniel Gultsch

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 week, 6 days

1
0
0 0

UPDATED: XEP-0066 (Out of Band Data)

by Daniel Gultsch

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 week, 6 days

1
0
0 0

2026

2025

2024

2023

Standards