- Standards

XMPP Council Agenda 2024-08-20

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 20 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 none 4) Items for voting a) XEP-0045: Presence sent to occupants of a destroyed room includes a <destroy/> https://github.com/xsf/xeps/pull/1365 Let’s come to an agreement here that includes the wording for the note. b) XEP-0388: Fix the XML Schema and examples https://github.com/xsf/xeps/pull/1369 c) XEP-0045: Explicitly use bare JIDs when operating on affiliations https://github.com/xsf/xeps/pull/1371 d) XEP-0045: Allow non-owners to retrieve owner and admin lists in non-anonymous rooms https://github.com/xsf/xeps/pull/1372 e) XEP-0402: Specify what clients should do if autojoin='0' in bookmark notifications https://github.com/xsf/xeps/pull/1373 5) Pending votes Technically some people on 'XEP-0045: Presence sent to occupants of a destroyed room includes a <destroy/>' but there is a new items for voting for that after the PR was modified. See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 year, 9 months

1
0
0 0

XMPP Council Agenda 2024-08-06

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 6 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-0054 (vcard-temp) https://xmpp.org/extensions/xep-0054.html - UPDATED: XEP-0386 (Bind 2) https://xmpp.org/extensions/xep-0386.html - UPDATED: XEP-0478 (Stream Limits Advertisement) https://xmpp.org/extensions/xep-0478.html - Proposed XMPP Extension: Jingle Audio/Video Conferences https://xmpp.org/extensions/inbox/av_conferences.html 4) Items for voting a) Proposed XMPP Extension: Jingle Audio/Video Conferences https://xmpp.org/extensions/inbox/av_conferences.html b) XEP-0045: Additional Ban List specifications https://github.com/xsf/xeps/pull/1359 c) XEP-0045: Remove references to using resourceparts when banning users https://github.com/xsf/xeps/pull/1360 d) XEP-0045: Improved wording of status code purpose https://github.com/xsf/xeps/pull/1361 e) XEP-0045: Improve 'Service Removes Non-Member' example https://github.com/xsf/xeps/pull/1362 f) XEP-0045: Clarify usage of presence stanzas when removing a non-member from a members-only room https://github.com/xsf/xeps/pull/1363 g) XEP-0045: Replace inappropriate RFC 2119 key word usage in §9.7 https://github.com/xsf/xeps/pull/1364 h) XEP-0045: Presence sent to occupants of a destroyed room includes a <destroy/> https://github.com/xsf/xeps/pull/1365 5) Pending votes none. I few expired since our last meeting. (see editor updates above) See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 year, 10 months

1
0
0 0

UPDATED: XEP-0478 (Stream Limits Advertisement)

by Daniel Gultsch

Version 0.2.0 of XEP-0478 (Stream Limits Advertisement) has been released. Abstract: This specification defines a way for an XMPP entity to announce the limits it will enforce for data received on a stream. Changelog: * Add the XML Schema. * Clarify that both children can be optional. * Fix indentation and one typo. (egp) URL: https://xmpp.org/extensions/xep-0478.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, 10 months

1
0
0 0

UPDATED: XEP-0386 (Bind 2)

by Daniel Gultsch

Version 1.0.1 of XEP-0386 (Bind 2) has been released. Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup. Changelog: Add an XML Schema. (egp) URL: https://xmpp.org/extensions/xep-0386.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, 10 months

1
0
0 0

UPDATED: XEP-0054 (vcard-temp)

by Daniel Gultsch

Version 1.3.0 of XEP-0054 (vcard-temp) has been released. Abstract: This specification provides canonical documentation of the vCard-XML format currently in use within the Jabber community. Changelog: Updated error cases to be compatible with . (gk) URL: https://xmpp.org/extensions/xep-0054.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, 10 months

1
0
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, 10 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, 10 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, 10 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, 10 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, 10 months

3
3
0 0

2026

2025

2024

2023

Standards