- Standards

Jingle user location
by Edward Tie 30 Jun '26

30 Jun '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 30 Jun '26

30 Jun '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 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

Fwd: [kitten] Call for adoption: draft-bouchez-scram-mcf-02 (Ends 2026-06-17)
by Dave Cridland 23 Jun '26

23 Jun '26

Is there any interest in the XMPP community for an MCF-based SCRAM? If so, is there any interest in working on this within the Kitten IETF Working Group? Dave. ---------- Forwarded message --------- From: Alexey Melnikov via Datatracker <noreply(a)ietf.org> Date: Wed, 3 Jun 2026 at 16:19 Subject: [kitten] Call for adoption: draft-bouchez-scram-mcf-02 (Ends 2026-06-17) To: <kitten(a)ietf.org>, <kitten-chairs(a)ietf.org>, < draft-bouchez-scram-mcf(a)ietf.org> As some interest was expressed in this document, this message starts a kitten WG Call for Adoption of: draft-bouchez-scram-mcf-02. This Working Group Call for Adoption ends on 2026-06-17 Abstract: This document specifies SCRAM-MCF, an extension to the Salted Challenge Response Authentication Mechanism (SCRAM) family of SASL mechanisms ([RFC5802]) and HTTP Digest extensions ([RFC7616], [RFC7677]). The extension replaces the PBKDF2-specific iteration count attributes i= and s= in the server-first-message with a generic Modular Crypt Format (MCF) descriptor f=. This allows servers to use modern memory- hard key derivation functions such as Argon2, SCrypt, or bcrypt while preserving the full security properties and message flow of SCRAM. The change is fully backward compatible: servers can continue sending i= and s= for legacy clients and only send f= (or both) when the client advertises support. This document is intended to be discussed and potentially adopted by the KITTEN working group. Feedback from the KITTEN WG is welcome on the kitten(a)ietf.org mailing list. Please reply to this message and indicate whether or not you support adoption of this Internet-Draft by the kitten WG. Comments to explain your preference are greatly appreciated. Please reply to all recipients of this message and include this message in your response. Authors, and WG participants in general, are reminded of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [2]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/ The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-bouchez-scram-mcf/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-bouchez-scram-mcf-02.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-bouchez-scram-mcf-02 _______________________________________________ Kitten mailing list -- kitten(a)ietf.org To unsubscribe send an email to kitten-leave(a)ietf.org

2 3

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