September 2025 - Standards

LAST CALL: XEP-0484 (Fast Authentication Streamlining Tokens)

by Daniel Gultsch

This message constitutes notice of a Last Call for comments on XEP-0484. Title: Fast Authentication Streamlining Tokens Abstract: This specification defines a token-based method to streamline authentication in XMPP, allowing fully authenticated stream establishment within a single round-trip. URL: https://xmpp.org/extensions/xep-0484.html This Last Call begins today and shall end at the close of business on 2025-01-27. 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!

1 month, 1 week

6
20
0 0

Navigation instructions for Atom Over XMPP (XEP-0277 and XEP-0472)

by Schimon Jehudah

Good day. About ===== I have recently suggested at project Movim to add navigational instructions to Atom entries (i.e. posts). I am still experimenting it, and it currently seems useful. Technicality ============ The idea is realized in a similar fashion to the classification of comments node with rel='replies' and title='comments'. https://xmpp.org/extensions/xep-0277.xml#comments Navigation ========== I advise to enable navigational instructions with rel='navigation' and title='previous' and title='proceed', and perhaps also title='index'. At the bottom of this page there are proceed or previous links to navigate and are generated from the instructions proposed above. https://journal.woodpeckersnest.eu/posts/2024-11-05-xmpp-as-the-internet/ Advantages ========== Navigational instructions would conveniently facilitate the creation of a CMS even over a single PEP node, without a compulsory need of having a PubSub service with multiple nodes to do so, by relating from post to post from within each posts. Navigational instructions would also incentivise the creation of articles that are segmented into parts of a series of posts, and portability thereof. Kind regards, Schimon

2 months, 1 week

1
1
0 0

LAST CALL: XEP-0440 (SASL Channel-Binding Type Capability)

by Daniel Gultsch

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!

2 months, 4 weeks

9
30
0 0

Question about Jingle RTP payload types (XEP-0167)

by Jacques Comeaux

Hi, I have a question about the handling of payload types in XEP-0167. The spec says that "The session-accept message SHOULD include a subset of the payload types sent by the initiator". When are two payload types considered equal? This is not obvious to me because there are optional attributes as well as parameters. I would think that definitely name, clockrate, and id need to match, but I'm not sure about the other attributes and the parameter values. I think a precise answer to this is needed to determine whether one list of payload types is a subset of another, and therefore whether a given session-accept meets this part of the specification. Here is an example from a call between two XMPP clients, Dino and Monal The session-initiate message sent by Dino includes this list of payload types: <payload-type id='111' channels='2' clockrate='48000' name='opus'> <parameter name='useinbandfec' value='1' /> </payload-type> <payload-type id='112' clockrate='32000' name='speex' /> <payload-type id='113' clockrate='16000' name='speex' /> <payload-type id='114' clockrate='8000' name='speex' /> <payload-type id='9' clockrate='8000' name='G722' /> <payload-type id='0' clockrate='8000' name='PCMU' /> <payload-type id='8' clockrate='8000' name='PCMA' /> And the session-accept message sent by Monal includes this list of payload-types: <payload-type clockrate='8000' name='PCMU' id='0' /> <payload-type channels='2' id='111' clockrate='48000' name='opus'> <parameter name='profile_level_id' value='4325392' /> <parameter name='useinbandfec' value='true' /> <parameter name='minptime' value='10' /> </payload-type> <payload-type clockrate='8000' name='G722' id='9' /> <payload-type clockrate='8000' name='PCMA' id='8' /> This currently causes a problem in Dino because one of the responder's payload types (opus) is judged to not be present in the list of sent payload types, because it is not (strictly speaking) equal to any of the sent payload types, because it has a different number of parameters. In this example, is the responder violating the spec by including extra parameters for the opus payload type, or is the initiator being too strict when comparing the payload types for equality? Thanks, Jacques

3 months, 2 weeks

2
1
0 0

Moving 'Discover Nodes' from XEP-0060 to XEP-0248

by Guus der Kinderen

Hello! Section 5.2 of XEP-0060 'Publish-Subscribe' describes how disco#items is used to discover nodes. Most of that section describes node discovery in node hierarchies and collection nodes. In version 1.12 of XEP-0060 text about collections was moved to XEP-0248 'PubSub Collection Nodes'. This specification contains a smaller paragraph on node discovery (which is also numbered 5.2). I would like to see the complexity of XEP-0060 be reduced. I believe that most, if not all of its section 5.2 should be moved to XEP-0248 and removed from XEP-0060. The suggested change should not affect backwards compatibility, as it doesn't result in a change of behavior: as far as I can see, the text only applies to hierarchies and collection nodes. The change therefore is permissible even considering XEP-0060 is Stable. Is there any objection to this? What would relevant Node Discovery content for XEP-0060 be (other than a reference to XEP-0248)? Kind regards, Guus

3 months, 3 weeks

2
11
0 0

XMPP Council Agenda 2025-09-30

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, September 30 2025 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-0317 (Hats) https://xmpp.org/extensions/xep-0317.html · Proposed XMPP Extension: Pubsub Node Bookmark https://xmpp.org/extensions/inbox/pubsub-node-bookmark.html 4) Items for voting a) Proposed XMPP Extension: Pubsub Node Bookmark https://xmpp.org/extensions/inbox/pubsub-node-bookmark.html b) XEP-0045: Fix 'roomsecret' field inconsistency https://github.com/xsf/xeps/pull/1464 5) Pending votes Dan on: XEP-0060 / XEP-0248: Improve separation of 'collections' XEP-0060 & XEP-0248: Default node-type specific configuration XEP-0070: extend security section Issue Last Call on 'XEP-0440: SASL Channel-Binding Type Capability' Daniel and Marvin on: XEP-0060 / XEP-0248: Improve separation of 'collections' XEP-0060 & XEP-0248: Default node-type specific configuration See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB 8) Close

3 months, 3 weeks

1
0
0 0

XEP-0045 'roomsecret' field definition

by Guus der Kinderen

Hi all, The 'roomconfig_roomsecret' data form field definition is not consistent. In XEP-0045, examples 157 and 165 use 'text-private'. The registry submission in paragraph 16.5.3 uses 'text-single'. The registry itself (https://xmpp.org/registrar/formtypes.html) uses 'text-private'. To me, this seems to boil down to a mistake in paragraph 16.5.3, which should be corrected to 'text-private'. Given that the XEP is Stable, can we bluntly do that? Kind regards, Guus

3 months, 3 weeks

2
1
0 0

Proposed XMPP Extension: Pubsub Node Bookmark

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub Node Bookmark Abstract: This specification defines a bookmark element pointing to a Pubsub node URL: https://xmpp.org/extensions/inbox/pubsub-node-bookmark.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

3 months, 3 weeks

1
0
0 0

UPDATED: XEP-0317 (Hats)

by Daniel Gultsch

Version 0.3.1 of XEP-0317 (Hats) has been released. Abstract: This specification defines a more extensible model for roles and affiliations in Multi-User Chat rooms. Changelog: Typos, completed some examples and paragraph clarifications thanks to badlop feedback. (tj) URL: https://xmpp.org/extensions/xep-0317.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.

3 months, 3 weeks

1
0
0 0

( XEP-0449) Are packless stickers legal?

by Nicolas Cedilnik

Hi all and llarma (XEP-0449 author) in particular, It's not clear in the spec whether it is allowed to have a <sticker> element without "pack" attribute. I know that the XEP is mostly about specifying how packs work; but I am looking for a way to convey the information that an attachment is a sticker. My use-case is between slidge and movim (for now, but maybe other client devs are interested…), and not in a "pack" context. We could use a non-standard element, but if you intended to make packless XEP-0449 stickers legal, let's use your XEP! Basically, we would just add an empty <stickerxmlns='urn:xmpp:stickers:0' />to an attachment (specified via oob and/or SIMS and/or SFS -_-). Did you intend to make this legal or should we use something else? Thanks for your reply, -- nicoco

3 months, 3 weeks

1
0
0 0

2026

2025

2024

2023

Standards September 2025