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!
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
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
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
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
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.
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.
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
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
Hi all,
I just submitted a revision to XEP-0503: Spaces. This is something
edhelas and I have been working on last week. I intend to implement it
in slidge, and he intends to implement UI for it in movim.
It is an almost complete rewrite vs the current state, which should not
be an issue since it has not been implemented anywhere yet. I tried to
incorporate the feedback I got, not only from the mailing but in various
MUCs and private conversations I had about the XEP here and there. In
short, a space is now just a pubsub node with appropriate configuration
and payload, and a space service is a pubsub service with feature
requirements.
As per the previous revision, the goal of this XEP is to establish a
minimal viable protocol for clients and servers to build around the
general concept of grouping several entities together. It requires
little to no additional support server-side and should work, in a very
basic form, with what's already available out there. I believe, that,
even in this basic form, it would be nice to have.
edhelas and I will also submit soon(ish) another XEP which could be _a_
way of defining how space-wide affiilations/roles/hats could work, by
using a "space's main MUC". That would allow for both optimising
presence traffic and enforcing consistency between the various rooms of
a space. This, of course, would require some additional server and
client support, but it looks like we can do something that is relatively
usable on any MUC-supporting client. I think it is best to have this in
a separate XEP, for future-proofness, since GC3 is just around the
corner. ;o)
Let me know what you think.
-- nicoco
