Hello,
I have updated the Jingle User Location ProtoXEP with clearer wording
after the Council discussion.
The updated draft is here:
https://github.com/xsf/xeps/pull/1550
The main clarification is that this proposal does not replace XEP-0080.
XEP-0080 remains the location payload. The problem this proposal tries
to solve is the call/session binding:
XEP-0080 tells where the user is, but it does not reliably tell for
which active Jingle call that location was shared.
PEP/PubSub is useful for general user-location publication, but for an
active call it does not clearly answer:
- which Jingle session / sid the location belongs to;
- whether the location was explicitly shared for this call;
- whether it is fresh, stale, one-time, or live;
- when call-scoped location sharing stops;
- whether a relay, accessibility assistant or future emergency gateway
may treat it as the location for the active call.
The revised direction is therefore narrower:
A small Jingle binding for XEP-0080 during an active call.
It reuses the existing XEP-0080 geoloc payload and adds Jingle session
context, stop-sharing/expiry wording, fallback wording and privacy
wording. It also explicitly avoids claiming to be an emergency-service
protocol by itself.
The reason I think this matters is accessibility and 112/911-readiness.
A deaf or speech-impaired user may be in a Total Conversation call with
audio, video, RTT, captions, relay/interpreter services or a future
emergency gateway. In that situation the peer or gateway should not have
to guess whether the latest XEP-0080/PEP item belongs to the current call.
Feedback is welcome, especially on whether this narrower “Jingle binding
for XEP-0080” direction is the right shape.
Kind regards,
Edward
|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 .
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.
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
