September 2024 - Standards

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 weeks, 4 days

9
30
0 0

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.

5 months, 1 week

3
3
0 0

XEP-0163 (Personal Eventing Protocol) Allow multiple publishers; XEP-0045 (Multi-User Chat) Allow PEP

by Schimon Jehudah

Good day! I am the developer of Slixfeed news bot, which is a syndication feed reader (Atom/RDF/RSS). This matter is also related to Morbot. See https://codeberg.org/TheCoffeMaker/Morbot/issues/13 Concern ------- I have to attempted experiment with PEP nodes, and my attempt has failed due to: XEP-0045 service-unavailable The feature requested is not supported by the conference XEP-0163 forbidden You're not allowed to create nodes Proposal -------- I suggest to enable PEP nodes for MUC JIDs too. I suggest to change the approach "One publisher per node.". See https://xmpp.org/extensions/xep-0163.html#approach-publisher > There is no need for multiple publishers to a PEP service, since by > definition the service generates information associated with only one > entity. The owner-publisher for every node is the bare JID of the > account owner. In order to allow a secondary "channel" interface for people and group chats, and also for other reasons (see further), it would be useful to: 1) Allow multiple publishers. 2) Allow PEP for MUC JIDs. By a "channel" interface, I mean, that should a news bot be included for a group chat, the updates would be sent to a PEP node of the group chat JID instead to the chat itself, which would keep the chat view cleaner. Example use cases: Number #3 represents the use of Morbot and Slixfeed, and is useful for forwarding of news journals. 1) Use : Inbox Affiliation : Publish-Only Publishers : JIDs which Presence is shared with or in Roster 2) Use : Collaboration (e.g. Pad, Whiteboard etc.) Affiliation : Publisher Publishers : Determined manually 3) Use : Updates Affiliation : Publish-Only Publishers : Determined manually Note ---- Slixfeed can use its own PEP nodes named after its subscribers respectively, albeit that would be more demanding on the server of which Slixfeed is operated on, than publishing to PEP nodes of other JIDs, and yet it would not be practical for group chat JIDs, which the bot also supports. Please advise. Kind regards, Schimon

11 months, 1 week

4
13
0 0

Proposed XMPP Extension: Happy Eyeballs

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Happy Eyeballs Abstract: When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack application that initiates a connect experiences significant connection delay compared to an IPv4-only application. This is undesirable because it causes the dual-stack initiating entity to have a worse user experience. This XEP defines how IETF's 'Happy Eyeballs' algorithm requirements that reduce this user-visible delay are applied to XMPP. URL: https://xmpp.org/extensions/inbox/xep-happy-eyeballs.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 year, 1 month

3
3
0 0

XEP-0484 and multiple devices

by Michael Uvarov

Hi, "XEP-0484: Fast Authentication Streamlining Tokens" is written without any considerations for multiple devices. With stuff like that "*For every client using FAST, have two token slots - 'current' and 'new'." *in it. I am kinda confused how the XEP could be considered in 2024. The moment we have two devices for the same user, the devices would start conflicting with each other, by revoking tokens of each other. The XEP should use namespaces (or be resource aware) for it to properly work. -- Best regards, Uvarov Michael

1 year, 1 month

2
3
0 0

XMPP Council Agenda 2024-09-24

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, September 24 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * UPDATED: XEP-0004 (Data Forms) * UPDATED: XEP-0264 (Jingle Content Thumbnails) * UPDATED: XEP-0313 (Message Archive Management) * Proposed XMPP Extension: Happy Eyeballs 4) Items for voting a) Proposed XMPP Extension: Happy Eyeballs https://xmpp.org/extensions/inbox/xep-happy-eyeballs.html b) XEP-0198: Clarify server enabling SM without requested resumption https://github.com/xsf/xeps/pull/1376 (modified) 5) Pending votes None See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 year, 1 month

1
0
0 0

UPDATED: XEP-0313 (Message Archive Management)

by Daniel Gultsch

Version 1.1.2 of XEP-0313 (Message Archive Management) has been released. Abstract: This document defines a protocol to query and control an archive of messages stored on a server. Changelog: * Fix JID and affiliation of the first two witches in the MUC example. * Fix duplicated 'id' in MUC example. * Fix indentation in examples. (egp) URL: https://xmpp.org/extensions/xep-0313.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-0264 (Jingle Content Thumbnails)

by Daniel Gultsch

Version 0.4.2 of XEP-0264 (Jingle Content Thumbnails) has been released. Abstract: This specification defines a way for a client to supply a preview image for Jingle content. Changelog: Restrict 'width' and 'height' to the 0..65535 range, instead of being unbounded integers. This is in accordance to XEP-0084 and XEP-0221 for instance. (egp) URL: https://xmpp.org/extensions/xep-0264.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-0004 (Data Forms)

by Daniel Gultsch

Version 2.13.2 of XEP-0004 (Data Forms) has been released. Abstract: This specification defines an XMPP protocol extension for data forms that can be used in workflows such as service configuration as well as for application-specific data description and reporting. The protocol includes lightweight semantics for forms processing (such as request, response, submit, and cancel), defines several common field types (boolean, list options with single or multiple choice, text with single line or multiple lines, single or multiple JabberIDs, hidden fields, etc.), provides extensibility for future data types, and can be embedded in a wide range of applications. The protocol is not intended to provide complete forms-processing functionality as is provided in the W3C XForms technology, but instead provides a basic subset of such functionality for use by XMPP entities. Changelog: Add section on empty and absent values. (gk) URL: https://xmpp.org/extensions/xep-0004.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

XMPP Council Agenda 2024-09-17

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, September 17 2024 at 16:00 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * UPDATED: XEP-0133 (Service Administration) * UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection) * UPDATED: XEP-0045 (Multi-User Chat) * UPDATED: XEP-0272 (Multiparty Jingle (Muji)) * NEW: XEP-0493 (OAuth Client Login) * NEW: XEP-0494 (Client Access Management) 4) Items for voting a) XEP-0004: Empty and absent values https://github.com/xsf/xeps/pull/1387 b) XEP-0264: Restrict 'width' and 'height' to the 0..65535 range https://github.com/xsf/xeps/pull/1366 c) XEP-0198: Clarify server enabling SM without requested resumption https://github.com/xsf/xeps/pull/1376 d) XEP-0313: Fix MUC archive example https://github.com/xsf/xeps/pull/1321 5) Pending votes None See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 year, 1 month

1
0
0 0

2025

2024

2023

Standards September 2024