- Standards

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.

4 months, 2 weeks

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

5 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.

5 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

5 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

5 months, 1 week

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

5 months, 1 week

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

5 months, 1 week

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

5 months, 1 week

1
0
0 0

UPDATED: XEP-0491 (WebXDC)

by Daniel Gultsch

Version 0.1.2 of XEP-0491 (WebXDC) has been released. Abstract: This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. Changelog: * Suggest what to use for selfAddr * Add acknowledgements (spw) URL: https://xmpp.org/extensions/xep-0491.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.

5 months, 2 weeks

1
0
0 0

UPDATED: XEP-0440 (SASL Channel-Binding Type Capability)

by Daniel Gultsch

Version 0.4.2 of XEP-0440 (SASL Channel-Binding Type Capability) has been released. Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients. Changelog: * Add an XML schema. * Mention that this specification does add a new namespace that should go to the registrar. * Fix indentation, typos, misuse of '' vs. </> for elements, etc. (egp) URL: https://xmpp.org/extensions/xep-0440.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.

5 months, 2 weeks

1
0
0 0

2024

2023

Standards ----- 2024 ----- December 2024 November 2024 October 2024 September 2024 August 2024 July 2024 June 2024 May 2024 April 2024 March 2024 February 2024 January 2024 ----- 2023 ----- December 2023

Standards