June 2025 - Standards

XMPP Council Agenda 2025-06-24

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, June 24 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-0284 (Shared XML Editing) https://xmpp.org/extensions/xep-0284.html 4) Items for voting a) XEP-0363: specify purpose/buckets when requesting slots https://github.com/xsf/xeps/pull/1445 5) Pending votes - Dan on everything from last week - Daniel on 'Proposed XMPP Extension: Data Forms File Input Element' - Goffi, technically on 'XEP-0388: Fix failure example sequence' but has been vetoed already in favor of "Should Daniel just fix the schema" See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB 8) Close

1 year

1
0
0 0

UPDATED: XEP-0284 (Shared XML Editing)

by Daniel Gultsch

Version 0.1.4 of XEP-0284 (Shared XML Editing) has been released. Abstract: This specification defines a protocol that enables two or more endpoints to collaboratively edit an XML object. The protocol is intended for use mainly over the Extensible Messaging and Presence Protocol (XMPP), either by existing instant messaging clients or by specialized editing clients. However, the protocol could also be used over a direct TCP connection rather than over XMPP. Changelog: * Fix the registrar section. * Format the glossary better. * Add missing <state/> wrappers in examples. * Write an XML Schema. (egp) URL: https://xmpp.org/extensions/xep-0284.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 year

1
0
0 0

Selective advertizing of activity and mood (XEP-0107 and XEP-0108)

by Schimon Jehudah

Greetings. Preface ------- I would want to advise to extend XEP-0107 (User Mood) and XEP-0108 (User Activity), so that it would be possible to selectively advertize of activities and moods. This is beneficial for both humans and machines. Because the examples for humans may be vague, I will write an obvious case for machines. Service ------- KaikOut is a moderation service (i.e. "bot", so called) for group chats. As with traffic signs, and unlike status messages, activity and mood are fixated, even though both have an option for custom text, and because of it, they can be used as constant and accurate indicators for activity and state of machines. That is, activities and moods can be used as signs, and also to signal of events. See further examples. Additionally, status messages, activities and moods serve different purposes, which is another reason to have an option of selective advertizing for activity and mood. Example ------- This is a realization of using activities and moods in a selective fashion over different group chats simultaneously. Ideas with XEP-0107: User Mood ------------------------------ amorous: When KaikOut writes good scores. annoyed: When KaikOut writes bad scores. ashamed: When KaikOut demotes a moderator. calm or bored: When group activity is under a certain level. happy or relaxed: When moderation activity is under a certain level. restless: When moderation activity is above a certain level. cautious or serious: Routine mood. remorseful or frustrated or sleepy: When KaikOut is disabled. proud: When KaikOut bans or kicks an occupant. ashamed or shocked: When a group chat owner pormotes a moderator which was demoted by KaikOut. surprised: When KaikOut is demoted. thankful: When KaikOut is set to be a moderator. Ideas with XEP-0108: User Activity ---------------------------------- working: When KaikOut writes scores. sleeping: When KaikOut is inactive. Reference: https://git.xmpp-it.net/sch/KaikOut/issues/36 Kind regards, Schimon

1 year, 1 month

2
2
0 0

XSF membership application period Q3 2025

by Alexander Gnauck

I have setup the membership application Wiki page for the application period Q3 2025 Applications are encouraged from developers and others who are actively involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki: https://wiki.xmpp.org/web/Membership_Applications_Q3_2025 If you don't have a wiki account, send your full name, preferred nickname and email address to me or one of the other Sysops: https://wiki.xmpp.org/web/Sysops Apply now!!! Thanks, Alex

1 year, 1 month

1
0
0 0

XMPP Council Agenda 2025-06-17

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, June 17 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-0384 (OMEMO Encryption) https://xmpp.org/extensions/xep-0384.html - UPDATED: XEP-0388 (Extensible SASL Profile) https://xmpp.org/extensions/xep-0388.html - UPDATED: XEP-0485 (PubSub Server Information) https://xmpp.org/extensions/xep-0485.html - UPDATED: XEP-0498 (Pubsub File Sharing) https://xmpp.org/extensions/xep-0498.html - Proposed XMPP Extension: Data Policy https://xmpp.org/extensions/inbox/data_policy.html - Proposed XMPP Extension: Data Forms File Input Element https://xmpp.org/extensions/inbox/data-form-file-element.html 4) Items for voting a) XEP-0388: Fix failure example sequence https://github.com/xsf/xeps/pull/1411 b) XEP-0080: Add "regioncode" element https://github.com/xsf/xeps/pull/1442 c) Proposed XMPP Extension: Data Policy https://xmpp.org/extensions/inbox/data_policy.html d) Proposed XMPP Extension: Data Forms File Input Element https://xmpp.org/extensions/inbox/data-form-file-element.html 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB 8) Close

1 year, 1 month

1
0
0 0

RFC 6121 section 8.5 "active resource" and "Connected Resource"

by Guus der Kinderen

Hi, Section 8.5.4 provides a summary of earlier sections. It uses the term "active resource" twice. This term is not used in any of the earlier sections. Conversely, the earlier sections use the term "Connected Resource" a couple of times. A "Connected Resource" is defined by RFC6121/6120 as "[has] bound a resource to the stream" Although the term "Connected Resource" is used in section 8.5, none of the specifications therein seem to apply to Connected Resources. The usage of the term "active resource" in section 8.5.4 could be an artifact of RFC3921/3920, which defines an "active resource" as: "Upon establishing a session, a connected resource (in the terminology of [XMPP-CORE]) is said to be an "active resource." Although section 8.5 advertises that it will define how stanzas related to connected resources are to be processed ("If there is at least one available resource or connected resource, how the stanza is processed depends on the stanza type.") it does not seem to do that. All definitions seem to depend on having at least one available resource (which is defined as a connected resource that has sent initial presence), leaving scenarios in which only connected resources are present, undefined. Am I misinterpreting this? If not, is this something that should be cleared up (or explicitly be left undefined)? As a practical example of a question that I believe is left unanswered: How should a server process a message stanza of type 'normal', addressed to a bare JID that represents a local user (the scenario of section 8.5.2.1.1 of RFC 6121) if the corresponding user only has one or more Connected Resources (but not any Available Resources)? I believe that there are many possible variations on this question, I'm limiting it to one to illustrate the larger issue that I described in this email. For additional context: this was discussed in the XSF's Discussion MUC earlier. Logs of that conversation can be found at https://logs.xmpp.org/xsf/2025-05-28#2025-05-28-a5d887bd6428222c Kind regards, Guus

1 year, 1 month

5
5
0 0

UPDATED: XEP-0498 (Pubsub File Sharing)

by Daniel Gultsch

Version 0.1.1 of XEP-0498 (Pubsub File Sharing) has been released. Abstract: This specification explains how to share files and optionally include directory structures similar to filesystems over XMPP Pubsub. It leverages XMPP Pubsub to enable notifications about file changes and manage permissions, providing users with real-time updates and control mechanisms. An optional mechanism is also specified for managing uploaded files. Changelog: Fix wrong shortname and add tags. (jp) URL: https://xmpp.org/extensions/xep-0498.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 year, 1 month

1
0
0 0

UPDATED: XEP-0485 (PubSub Server Information)

by Daniel Gultsch

Version 0.1.1 of XEP-0485 (PubSub Server Information) has been released. Abstract: This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub. Changelog: * Fixed references to XEP identifier. (gdk) URL: https://xmpp.org/extensions/xep-0485.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 year, 1 month

1
0
0 0

UPDATED: XEP-0388 (Extensible SASL Profile)

by Daniel Gultsch

Version 1.0.3 of XEP-0388 (Extensible SASL Profile) has been released. Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility. Changelog: * Add missing minOccurs='0' to additional-data in <continue/> in XML schema. (lnj) URL: https://xmpp.org/extensions/xep-0388.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 year, 1 month

1
0
0 0

UPDATED: XEP-0384 (OMEMO Encryption)

by Daniel Gultsch

Version 0.9.0 of XEP-0384 (OMEMO Encryption) has been released. Abstract: This specification defines a protocol for end-to-end encryption in one-to-one chats, as well as group chats where each participant may have multiple clients per account. Changelog: Device labels must be signed Allow empty device list in XML schema Reworded security consideration that could be interpreted as forbidding trust mechanisms like BTBV/TOFU Added section about dealing with lack of presence subscription Removed reference to omemo-session-healing (th) URL: https://xmpp.org/extensions/xep-0384.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 year, 1 month

1
0
0 0

2026

2025

2024

2023

Standards June 2025