- Standards

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

How will MEP / XEP-0316 handle unstable fullJIDs?
by Greatsword 19 Jun '26

19 Jun '26

Just had a read of XEP-0316: MUC Eventing Protocol, and it seems interesting and useful, but I'm wondering what happens to the MEP nodes owned by a particular occupant. The XEP states... > An occupant does so by sending a publish-subscribe publish request to the occupant's Occupant JID <room@service/nick> (similar to the way in which publishing via PEP happens by sending a request to the user's bare JID <user@host>). For instance, the following example shows how a room occupant would inform the other occupants about an event of interest. which would mean that interested parties would be subscribing to room@service/nick for their MEP nodes, but this could change from the user leaving or changing their nick. Is it just meant to be a sort of temporary live thing where you can ad-hoc send these events and then they just go away when you leave? or could this be attached to something more stable, like Occupant-ID. Thanks all! -- - greatsword

1 1

How will MEP / XEP-0316 handle unstable fullJIDs?
by Greatsword 19 Jun '26

19 Jun '26

Just had a read of XEP-0316: MUC Eventing Protocol, and it seems interesting and useful, but I'm wondering what happens to the MEP nodes owned by a particular occupant. The XEP states... > An occupant does so by sending a publish-subscribe publish request to the occupant's Occupant JID <room@service/nick> (similar to the way in which publishing via PEP happens by sending a request to the user's bare JID <user@host>). For instance, the following example shows how a room occupant would inform the other occupants about an event of interest. which would mean that interested parties would be subscribing to room@service/nick for their MEP nodes, but this could change from the user leaving or changing their nick. Is it just meant to be a sort of temporary live thing where you can ad-hoc send these events and then they just go away when you leave? or could this be attached to something more stable, like Occupant-ID. Thanks all! -- - greatsword

1 0

XMPP Spaces URIs
by Timothée Jaussoin 16 Jun '26

16 Jun '26

Hi! XMPP Spaces are now described in https://xmpp.org/extensions/xep-0503.html . A XMPP Space is a Pubsub node that contains bookmarks pointing to MUCs. We would like to have a proper Space URI that allow users to invite easily others to their Spaces. This will be added as a section to XEP 0503. So far a Pubsub node is described in https://xmpp.org/extensions/xep-0060.html#impl-uri I'd like to have something short and transparent so I'm proposing something like this: Proposal 1: xmpp:spaces.server.tld?;node=x56ae32&space I'm wondering if something shorter like this is possible ? (where the client is resolving the "space" parameter as the Pubsub node) Proposal 2: xmpp:spaces.server.tld?;space=x56ae32 The goals are * to prevent non "space-ready" XMPP clients to open it as a Pubsub node by mistake * have something short and easily shareable (Discord is having something like this https://discord.gg/AP5HFj7w) If one of the proposals is okay for you I'll propose a PR on 0503 and make the changes in Movim (I'm sure nicoco will be able to do it in Slidge, the other 0503 implementation). Because this is having effect on the XMPP uris format I'm wondering if there's some kind of rules or specific requests to follow ? Regards, edhelas

3 5

Proposed XMPP Extension: XMPP Decentralized ID (XID)
by Daniel Gultsch 16 Jun '26

16 Jun '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: XMPP Decentralized ID (XID) Abstract: XMPP Decentralized ID (XID) is a DNS independent XMPP entity identifier. This specification describes how to generate, use, and handle them. URL: https://xmpp.org/extensions/inbox/xid.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

10 21

Proposed XMPP Extension: Payment Required
by Daniel Gultsch 15 Jun '26

15 Jun '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Payment Required 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 supporting multiple concurrent payment options, including bank transfers (SEPA, IBAN, UPI) and instant-settlement networks (Lightning Network), and integrates with the existing CAPTCHA challenge mechanism defined in XEP-0158. URL: https://xmpp.org/extensions/inbox/payment-required.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

8 11

XSF membership application period Q3 2026
by Alexander Gnauck 15 Jun '26

15 Jun '26

I have setup the XSF membership application Wiki page for the application period Q3-2026 Applications are encouraged from developers and others who are actively involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki: https://wiki.xmpp.org/web/Membership_Applications_Q3_2026 If you don't have a wiki account, send your full name, preferred nickname and email address to me or one of the other Sysops: https://wiki.xmpp.org/web/Sysops When you need help with your application then don't hesitate to contact me directly Apply now!!! Thanks, Alex

1 0

Proposed XMPP Extension: Jingle Synchronized Real-Time Text
by Daniel Gultsch 15 Jun '26

15 Jun '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle Synchronized Real-Time Text Abstract: This specification defines a Jingle application extension for negotiating real-time text as part of the same conversational session as audio and video. URL: https://xmpp.org/extensions/inbox/jingle-rtt-sync.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

5 8