May 2024 - Standards

Proposed XMPP Extension: Jingle Remote Control

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle Remote Control Abstract: This specification defines a way to remotely control a device using local peripheral inputs. URL: https://xmpp.org/extensions/inbox/remote-control.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

1 month, 3 weeks

10
43
0 0

XEP proposal: filtering chat notifications

by avidseeker7＠protonmail.com

I am an end-user using two XMPP clients: for desktop and mobile. Since there is no XEP standard for muting conversations, the two clients implement this in their own way, and they are out of sync: the contacts I have muted on phone are not automatically muted on desktop and vice-verse. While looking to see if XMPP have such XEP, I found these extensions from Tigase that might be helpful in writing an official XEP: https://xeps.tigase.net/docs/push-notifications/filters

1 month, 3 weeks

6
11
0 0

Send-only role

by avidseeker7＠protonmail.com

I am an end-user, and having used Telegram for some time, it offers a more fine-grained control over members of a group. One of those controls is to prevent group members (usually bots) from reading group messages, and only allow them to send messages, following the principle of least privilege. A more complex set up would be partially allow them to read messages directed to them and exclude the rest of messages. E.g: by specifying a command like /bot, the bot can read the content of that message to process it then reply back.

1 month, 4 weeks

4
5
0 0

XMPP Council Agenda 2024-05-21

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, May 21 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 * Proposed XMPP Extension: Jingle Remote Control 4) Items for voting a) Move 'XEP-0440: SASL Channel-Binding Type Capability' to stable https://xmpp.org/extensions/xep-0440.html b) Proposed XMPP Extension: Jingle Remote Control https://xmpp.org/extensions/inbox/remote-control.html 5) Pending votes none See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

2 months

1
0
0 0

LAST CALL: XEP-0421 (Anonymous unique occupant identifiers for MUCs)

by Daniel Gultsch

This message constitutes notice of a Last Call for comments on XEP-0421. Title: Anonymous unique occupant identifiers for MUCs Abstract: This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of anonymous users. URL: https://xmpp.org/extensions/xep-0421.html This Last Call begins today and shall end at the close of business on 2024-05-27. 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 months, 1 week

5
7
0 0

XEP-0424/425 Feedback

by Philipp Hörist

Hi, Some feedback while trying to implement these XEPs XEP-0424 1) The schema mentions <xs:attribute name='by' type='xs:string' use='optional'/> But the XEP does not mention the attribute, what is the purpose? 2) > When replacing the original message with a tombstone, the original contents (i.e. the <body/> and any related elements which might leak information about the original message) get replaced with a <retracted/> element which MUST include an 'id' attribute referring to the original message Why does the element MUST have an id attribute? its a element inside the <message> which already has the id, or in case of groupchat its inside a mam wrapper which has a stanza id, in all cases its perfectly clear that the retracted element belongs to the actual message wrapping it, maybe im missing something obvious here but i dont see a need for this id attribute at all. Example 7 > For messages of type 'groupchat', the stanza's Unique and Stable Stanza IDs (XEP-0359) <https://xmpp.org/extensions/xep-0359.html> [4 <https://xmpp.org/extensions/xep-0424.html#nt-idm41385450875712>] 'origin ID' MUST NOT be used for retractions Example mentions origin-id in groupchat context <message type="groupchat" from="romeo(a)montague.example" to="lord(a)capulet.example" id="wrong-recipient-1"> <retracted stamp='2019-09-20T23:09:32Z' xmlns='urn:xmpp:message-retract:1' id='origin-id-1'/> </message> XEP-0425 1) > A Message Archive Management (XEP-0313) <https://xmpp.org/extensions/xep-0313.html> [6 <https://xmpp.org/extensions/xep-0425.html#nt-idm34711750431632>] service MAY replace the contents of a message, that was retracted due to moderation, with a 'tombstone' similar to the one described in Message Retraction (XEP-0424) <https://xmpp.org/extensions/xep-0424.html> [5 <https://xmpp.org/extensions/xep-0425.html#nt-idm34711750445088>]. How similiar? The tombstone text does not mention seemingly important MUST rules from XEP 0424 For example > Some clients may have been offline while the retraction was issued. The archiving service therefore MUST store the retraction message, regardless of whether the original message is deleted or replaced with a tombstone. the above mentioned MUST rule about the id attribute in the <retracted> element, seems to be not important anymore in moderation, at least the id attribute is not found anymore in the tombstone. Im not saying we need to copy text 1:1 between the XEPs, but should the XEP not go into more detail what exactly the differences are, and what exactly from 0424 applies? Thanks Regards Philipp

2 months, 1 week

2
1
0 0

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 months, 2 weeks

8
13
0 0

UPDATED: XEP-0045 (Multi-User Chat)

by Daniel Gultsch

Version 1.34.6 of XEP-0045 (Multi-User Chat) has been released. Abstract: This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc. Changelog: Remove contradicting keyword on sending subject in §7.2.2. (pep) URL: https://xmpp.org/extensions/xep-0045.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.

2 months, 2 weeks

1
0
0 0

UPDATED: XEP-0030 (Service Discovery)

by Daniel Gultsch

Version 2.5.0 of XEP-0030 (Service Discovery) has been released. Abstract: This specification defines an XMPP protocol extension for discovering information about other XMPP entities. Two kinds of information can be discovered: (1) the identity and capabilities of an entity, including the protocols and features it supports; and (2) the items associated with an entity, such as the list of rooms hosted at a multi-user chat service. Changelog: Add note about some entities not advertising the feature. (pep) URL: https://xmpp.org/extensions/xep-0030.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.

2 months, 2 weeks

1
0
0 0

XMPP Council Agenda 2024-05-07

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, May 7 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 4) Items for voting a) PR: XEP-0030: Note known wart https://github.com/xsf/xeps/pull/1341 b) PR: XEP-0045: Remove conflicting keyword in §7.2.2 https://github.com/xsf/xeps/pull/1342 5) Pending votes Marvin on * Issue Last Call on 'XEP-0421: Anonymous unique occupant identifiers for MUCs' (expires today) See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

2 months, 3 weeks

1
0
0 0

2024

2023

Standards May 2024

2024

2023

Standards May 2024 ----- 2024 ----- July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards May 2024