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
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.
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.
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.
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
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
[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
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.
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
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
