Version 0.5 of XEP-0440 (SASL Channel-Binding Type Capability) has
been released.
Abstract:
This specification allows servers to annouce their supported SASL
channel-binding types to clients.
Changelog:
* Address a possible MITM attack vector by making the tls-server-end-
point channel-binding mandatory to implement
* Remove the whole 'Interaction with SASL mechanisms' section and
replace it with 'Business Rules'
* Rework whole 'Security Considerations' section
* Some minor editorial changes
* Add Thilo Molitor as author (tm)
URL: https://xmpp.org/extensions/xep-0440.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.
This message constitutes notice of a Last Call for comments on
XEP-0440.
Title: SASL Channel-Binding Type Capability
Abstract:
This specification allows servers to annouce their supported SASL
channel-binding types to clients.
URL: https://xmpp.org/extensions/xep-0440.html
This Last Call begins today and shall end at the close of business on
2024-05-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!
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Jingle Content Category
Abstract:
This specification defines an XMPP extension to negotiate the use of
Session Description Protocol (SDP) media- level attribute 'content' as
defined by RFC 4796 with Jingle RTP sessions
URL: https://xmpp.org/extensions/inbox/jingle-content-category.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Forums
Abstract:
This specification describes how to implement XMPP-based discussion
forums.
URL: https://xmpp.org/extensions/inbox/forums.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
Version 1.35.2 of XEP-0045 (Multi-User Chat) has been released.
Abstract:
This specification defines an XMPP protocol extension for multi-user
text chat, whereby multiple XMPP users can exchange messages in the
context of a room or channel, similar to Internet Relay Chat (IRC). In
addition to standard chatroom features such as room topics and
invitations, the protocol defines a strong room control model,
including the ability to kick and ban users, to name room moderators
and administrators, to require membership or passwords in order to
join the room, etc.
Changelog:
Fix inconsistency in 'roomconfig_roomsecret' data form field
definition. (gk)
URL: https://xmpp.org/extensions/xep-0045.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.0 of XEP-0506 (No-reply JIDs) has been released.
Abstract:
This specification defines a way for JIDs to advertise that they don’t
accept incoming chat messages.
Changelog:
Accepted as Experimental by council vote (dg)
URL: https://xmpp.org/extensions/xep-0506.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 1.0.1 of XEP-0392 (Consistent Color Generation) has been
released.
Abstract:
This specification provides a set of algorithms to consistently
generate colors given a string. The string can be a nickname, a JID or
any other piece of information. All entities adhering to this
specification generate the same color for the same string, which
provides a consistent user experience across platforms.
Changelog:
Add missing saturation and lightness information to compute the test
vectors. (egp)
URL: https://xmpp.org/extensions/xep-0392.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 everyone,
I'm submitting a new ProtoXEP named Jingle Content Category.
The goal of this new XEP is pretty straightforward as described in its
introduction:
/This specification defines an XMPP extension to negociate the use
of Session Description Protocol (SDP) media-level attribute
'content' as defined by RFC 4796 with Jingle RTP sessions/
This XEP is really useful for clients, like Movim, that are handling
several streams, especially video ones, per user and wants to know how
to deal with them in their UI and flows (prioritize the screen-sharing
by putting it in full screen, always put the sign-language stream in the
bottom right corner...).
I'd also invites clients that are already implementing Jingle such as
Gajim, Dino, Conversations, Libervia to tag their contents using this XEP ;)
You can find my PR there: https://github.com/xsf/xeps/pull/1475
Regards,
edhelas
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
2025-10-28.
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!
