July 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!

1 week, 2 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.

4 months, 3 weeks

3
3
0 0

Bibliography and PubSub

by Schimon Jehudah

Greetings XSF! Thanks to Mr. Timothée Jaussoin (alias "edhelas") who is responsible for "XEP-0472: Pubsub Social Feed" I am interested and investigate about developing and utilizing XMPP PubSub. I am working on a couple of XMPP chat bots to which I will integrate support for PubSub. * Slixfeed (integrated) Slixfeed is a news bot of which PubSub support is almost done. It will use of affiliation='publisher' as defined in XEP-0060 to post news items to PubSub nodes https://git.xmpp-it.net/sch/Slixfeed * BukuBot (not yet integrated) BukuBot is a new chat bot which I contemplate on adding PubSub support in order to make link directories sharable, yet I do not think it would be wise to utilize node `urn:xmpp:links:0` for this purpose. Because of this, I would like to discuss of a new XEP which probably would be similar to XEP-0277 and XEP-0472, yet it would be specifically aimed at bibliography management. Such XEP would be utilized to share Book and Scholar citations, URLs (Gemini, Gopher, HTTP, XMPP), and other type of references over XMPP PubSub. I would be thankful for you to help and share your thoughts on this matter. Kind regards, Schimon

1 year, 2 months

3
12
0 0

Reconsider type signs

by Schimon Jehudah

Greetings! Years ago, someone here has posted to one of the Jabber mailing list a suggestion to use "software purpose signs" (this is a phrase I use), similarly to traffic signs and "creative commons" signs to which he has made a reference. Considering software such as LeechCraft, Libervia, Movim, and now Rivista which are extensively or solely related to publishing; and Considering a download manager software* which allows to be remotely controlled via XMPP; and Considering gateways, such as Slidge; and Considering devices (aka IoT) that incorporate XMPP; and Considering chat bots. I think it is definitely a good idea to make use of signs as an optional practice to categorize thhe type of software, and to make new people to be aware that XMPP is not only for IM as too many of them, including developers, might think. * I do not recall the name of that software. I recall that it was published on launchpad.net and it was written in Python. Kind regards, Schimon

1 year, 3 months

1
0
0 0

XEP-0439: Quick Responses - Feedback

by Philipp Hörist

Hi, I looked through the XEP and i find a few things not great. Im not getting the difference between <response> and <action>. And the XEP makes no attempt to describe it. A question that i answer with "Yes" or "No" should be a response, but a Question that i answer with "Merge" is an action? Seems completely random. The XEP mentions no use case that can only be done with <response>, i see no reason at all as a client developer to implement this. Now for <actions>, the id attribute is under specified, it seems essential to the whole thing working at all. Should this be a globally unique ID? Or at least unique per remote JID? In my opinion <action> should have another id attribute (of course differently named) referencing the message it belongs to. We have this pattern with message errors, iq responses, reactions, message replies, moderation, etc., we should not break this pattern here for no gain, just because its theoretically possible to still match this if the id is globally unique. I think this is a really nice idea and feature, but it should fit in with current XEP patterns, and better describe what <response> even should accomplish. Is the original Author still around? I also looking forward to other peoples opinions.

1 year, 3 months

4
9
0 0

Encrypted peer-to-peer XML channel

by Tim Henkes

Hi folks, I've been brainstorming a mechanism for offline history transfer (i.e. one client fetches the offline message history from another client). For that, an encrypted direct client-to-client XML channel would be neat. 1. Are direct client-to-client XML channels a thing? I found XEP-0247 [1], which looks alright on first read-through but is deferred since 2010. Does someone more familiar with the topic know why the XEP was abandoned and whether it could realistically be revived or if there is a better alternative now? 2. Are encrypted direct client-to-client channels a thing? There is JET [2], but it seems to focus on key negotiation (which I would do differently) and file transfers, which I don't need either. I don't see how a bidirectional data channel/stream would be encrypted using JET. There's also a XEP called jingle-xtls [3] in the Inbox, but it's even more abandoned than XEP-0247 and also seems to focus mostly on the key negotiation, which again I would do differently. Next to these questions I would be interested in the general sentiment and ideas for workarounds (e.g. "p2p is cursed, just send encrypted stanzas via the server as usual" or "just use a simple binary format and don't bother with a fully fledged XML stream"). Thanks :D Tim [1] https://xmpp.org/extensions/xep-0247.html [2] https://xmpp.org/extensions/xep-0391.html [3] https://xmpp.org/extensions/inbox/jingle-xtls.html

1 year, 3 months

6
13
0 0

XEP-0045: Stanzas when loosing membership in member-only room

by Guus der Kinderen

Hello! Section 9.4 of XEP-0045 Multi-User Chat defines XMPP interaction when a member of a room gets their membership removed. In the last few lines of the section, the section describes how, in a members-only room, the affected user is to be removed from the room. Why does example 128 "Service Removes Non-Member" contain two stanzas (their difference only being a 'actor' element)? See https://xmpp.org/extensions/xep-0045.html#example-128 Kind regards, Guus

1 year, 3 months

2
2
0 0

XEP-0045 definition of Ban List JIDs

by Guus der Kinderen

Hello! XEP-0045 Multi-User Chat, section 9.2 defines that the ban list is always based on a user's bare JID (in the first paragraph). That same section also defines a matching order (in the last paragraph) in which items with a full JID are explicitly included. This seems to contradict each other. Am I misunderstanding this part of the specification? Assuming that full JID values aren't to be used on a ban-list, should the matching order as defined in the XEP be modified to not refer to full JIDs? Kind regards, Guus

1 year, 3 months

3
3
0 0

XEP-0045 combining valid and invalid ban list modification in one request

by Guus der Kinderen

Hello! XEP-0045 Section 9.1 defines that: - a user cannot be banned by an admin with a lower affiliation. - if an admin or owner attempts to ban himself, the service MUST deny the request. Section 9.2, that deals with modifying the ban list of a room (potentially applying changes that affect more than one participant) does not mention these cases. It stands to reason that similar definitions must apply. To me, this raises the question of dealing with ban list modification requests that contain both 'valid' as well as 'invalid' modifications. I do not believe that the XEP clearly specifies how to deal with these. I would think that the entire request is to be rejected (as opposed to only the 'valid' modifications' be applied). Can we add this explicitly in the XEP? Kind regards, Guus

1 year, 3 months

2
2
0 0

XMPP Council Agenda 2024-07-09

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, July 9 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-0440 (SASL Channel-Binding Type Capability) https://xmpp.org/extensions/xep-0440.html - UPDATED: XEP-0491 (WebXDC) https://xmpp.org/extensions/xep-0491.html 4) Items for voting a) XEP-0386: Add an XML Schema https://github.com/xsf/xeps/pull/1356 5) Pending votes Travis and Daniel are pending on - XEP-0054: Updated error cases to be compatible with RFC 6121 See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 year, 3 months

1
0
0 0

2025

2024

2023

Standards July 2024