- Standards

Question about Jingle RTP payload types (XEP-0167)
by Jacques Comeaux 06 Oct '25

06 Oct '25

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

2 1

A plea for help with Publishing Over XMPP
by Schimon Jehudah 05 Oct '25

05 Oct '25

Good evening. I am developing a journal publishing system with XMPP support. I am experimenting with the commenting system of XEP-0277, and, according to Movim, it seems that I fail to create nodes with appropriate properties. I suppose that I fail, because Movim indicates that comments are closed for posts that I publish. I would be glad for any help. Thank you. Schimon

1 0

Question about hash element in File Transfer XEPs
by Philipp Hörist 05 Oct '25

05 Oct '25

Hi, There are multiple filetransfer XEPs like e.g. XEP-0385 / XEP-0447 / XEP-0396 They define a hash element, but its not clear to me if the hash is after encryption or before, if the file should be transferred encrypted. If it is after encryption, the hash can only be used in edge cases for caching purposes (look up if we have this file already) because encryption keys change with each file transfer hence the hash of the encrypted file would change. Regards Philipp

1 0

Moving 'Discover Nodes' from XEP-0060 to XEP-0248
by Guus der Kinderen 01 Oct '25

01 Oct '25

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

2 11

XMPP Council Agenda 2025-09-30
by Daniel Gultsch 30 Sep '25

30 Sep '25

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

1 0

XEP-0045 'roomsecret' field definition
by Guus der Kinderen 30 Sep '25

30 Sep '25

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

2 1

Proposed XMPP Extension: Pubsub Node Bookmark
by Daniel Gultsch 29 Sep '25

29 Sep '25

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.

1 0

UPDATED: XEP-0317 (Hats)
by Daniel Gultsch 29 Sep '25

29 Sep '25

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.

1 0

( XEP-0449) Are packless stickers legal?
by Nicolas Cedilnik 27 Sep '25

27 Sep '25

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

1 0

New ProtoXEP: Pubsub Node Bookmark
by Timothée Jaussoin 20 Sep '25

20 Sep '25

Hi, I'm submitting a new XEP named Pubsub Node Bookmark after the work we did with nicoco on the XEP-0503: Spaces. This XEP is quite simple and defines a new <pubsub-node/> element that act as a bookmark that point to a Pubsub Node. The goal is to have something very similar to the <conference/> node defined in XEP-0402: PEP Native Bookmarks, a <pubsub-node/> is even having an <extensions/> item that is compatible with the ones of XEP-402, allowing Pubsub Node Bookmarks to be pinned (https://xmpp.org/extensions/xep-0402.html) or having custom notifications settings (https://xmpp.org/extensions/xep-0492.html) As you see in the example bellow the id is defined the same way as the ids in XEP-0402 but this time by using a Pubsub URI. Here is an example: <itemid='bookmarks.library.org?;node=books'><pubsub-nodexmlns="urn:xmpp:pubsub-node_bookmark:0"jid="bookmarks.library.org"node="movies"><extensions><pinnedxmlns='urn:xmpp:bookmarks-pinning:0'/></extensions></pubsub-node></item> Why this XEP ? A Space is defined as a list of items in a Pubsub Node, those items can be MUCs but also Pubsub Nodes (for example if you want to have a Blog or Newsletter in your Space). Movim is using something a bit similar in an old XEP I defined in 2013: https://xmpp.org/extensions/xep-0330.html, if Pubsub Node Bookmark is published, I'll update XEP-0330 to be based on that one. You can find a HTML version there: https://movim.eu/xeps/pubsub-node-bookmark.html I'd be happy to get feedbacks to see how things can be improved :) Regards, edhelas

2 1