May 2025 - Standards

Proposed XMPP Extension: PubSub Server Information

by kevin.smith＠isode.com

The XMPP Extensions Editor has received a proposal for a new XEP. Title: PubSub Server Information Abstract: This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub. URL: https://xmpp.org/extensions/inbox/pubsub-server-info.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

2 days, 7 hours

3
3
0 0

Moderating PubSub

by Schimon Jehudah

Good day, to one and all. I am considering to utilize a PubSub service as a public discussion board; and, as a public discussion board, it should be free for all. I was wondering whether an approval or other type of moderation mechanism is specified for PubSub. Kind regards, Schimon

1 week, 1 day

5
9
0 0

XEP-0115: Mismatched 'node' attribute value when detecting capabilities

by Guus der Kinderen

Hi all, This follows a discussion the XSF's Standards Discussion MUC. Logs start at https://logs.xmpp.org/xsf/2025-05-18 (and continue into the next days). XEP-0115: Entity Capabilities describes how capabilities from the "generating entity" can be discovered by a "requesting entity" in section 6.2. To do this, the "requesting entity" sends a disco#info request (that MUST include a disco 'node' attribute for backwards-compatibility). The 'node' attribute value is generated in a way that results in an application-specific value that will be specific to the application that generated the string as well as the capabilities that are currently advertised by that application. What the XEP does not describe, is what is to happen when the requesting entity uses in their request a 'node' attribute value that is different from what the generating entity would produce (given its current configuration). Since providing the value, the generating entity could have undergone configuration changes making available a different set of capabilities, thus making the original value outdated. The XEP is improved by explicitly describing this scenario, by defining what should happen when a requesting entity uses a conflicting 'node' attribute value. I can think of a number of options: 1. If the 'node' attribute value sent by the requesting entity is recognized by the generating entity as a valid value in some context (eg: a value that represents an earlier state of offered capabilities), the generating entity could respond with the corresponding capabilities. Downsides: the requesting entity may take this as an indication that this represents the _current_ capabilities of the requesting entity, when that may not be the case. This approach can't be used if the generating entity does not recognize the value 2. The request could be answered with an error (eg: item-not-found). Downside: the requesting entity, that only performs this request because it's interested in the current capabilities of the generating entity, needs to do another round trip to get the answers it is looking for. 3. The request could be answered with a response in which the generating entity uses the new/up-to-date 'node' attribute value (it explicitly does not echo back the value that was in the request). Downside: there is a potential backwards compatibility issue for existing implementations that currently use another approach. They may end up mismatching 'node' attribute values and associated capabilities. Given the wording in section 6.2, specifically the definition that the requesting entity is to include the 'node' attribute for backwards compatibility, seems to suggest that the responding entity may not have a need for this value. That, to me, suggests that option 3 is most appropriate. I suggest that section 6.2 of XEP-0115 is modified to include an explicit description of option 3. The backwards-incompatibility issues are arguably existing only because of unspecified behavior. I do not see how such issues would be significantly affecting functionality. As the XEP is currently in state Stable, backwards incompatible changes are allowable. Thoughts? Kind regards, Guus

3 weeks

1
0
0 0

mailing list move

by Peter Saint-Andre

We're in the midst of moving this email discussion list from one server to another. You might be asked to re-confirm your subscription. Peter

1 month

1
0
0 0

2025

2024

2023

Standards May 2025

2025

2024

2023

Standards May 2025 ----- 2025 ----- June 2025 May 2025 April 2025 March 2025 February 2025 January 2025 ----- 2024 ----- December 2024 November 2024 October 2024 September 2024 August 2024 July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards May 2025