October 2024 - Standards

A public profile page
by Schimon Jehudah 29 Oct '24

29 Oct '24

Good day, one and all! I want to work on an XEP which would define "link collections", which I think would also be useful for FASI (HTML invite page for XMPP), which already indicates of articles, when articles are present (see attached image). See example profiles under "New Members" at https://libertylinks.io Would Data Forms be the appropriate mean to achieve it? Kind regards, Schimon

3 6

UPDATED: XEP-0491 (WebXDC)
by Daniel Gultsch 28 Oct '24

28 Oct '24

Version 0.1.3 of XEP-0491 (WebXDC) has been released. Abstract: This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. Changelog: * Clarifications and wording * Better references for WebXDC spec (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.

1 0

UPDATED: XEP-0394 (Message Markup)
by Daniel Gultsch 28 Oct '24

28 Oct '24

Version 0.3.0 of XEP-0394 (Message Markup) has been released. Abstract: This specification provides an alternative to XHTML-IM with rigid separation of content and markup information, improving the resilience against spoofing and injection attacks. Changelog: Add support for strong emphasis, declaring langauge on code blocks and making lists ordered. (lmw) URL: https://xmpp.org/extensions/xep-0394.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 0

XEP-0045 join events
by Guus der Kinderen 18 Oct '24

18 Oct '24

Hello XMPP aficionados! For a client joining a MUC, XEP-0045 defines a very strict order of events (section 7.1). Is it allowable that a server sends _more_ events (that are not in the list specified in XEP-0045)? I've observed that in the wild, at least one implementation sends a presence stanza 'from the room itself' (with CAPS), preceding the events defined in section 7.1. There is an argument to be made that the XEP defines the order of the events, but leaves room for there to be 'more' events. One could argue that this is in line with the extensible nature of XMPP. On the other hand, I think that it's fair to say that this is stretching things to an extent where it is not unreasonable for implementations to not account for this (thus introducing potential interop issues). I would like for the XEP to be more explicit, and either explicitly allow or disallow this behavior. I have not quite made my mind up which way I lean, to be honest. I'm interested in learning about the views on this from the community. For context, this has been previously discussed in the XSF Discussion MUC. This is a link to the public message archive of that discussion. https://logs.xmpp.org/xsf/2024-09-07#2024-09-07-78b71f7983a88d14 Kind regards, Guus

3 3

closing the IoT SIG
by Peter Saint-Andre 17 Oct '24

17 Oct '24

I'd like to propose that we close the Internet of Things Special Interest Group, which as far as I can see has been inactive. This would involve moving XEP-0381 to Deprecated or Obsolete (the interim step of Deprecated in accordance with XEP-0001 seems unnecessary, but I'll leave that to the Council should it decide to act on this proposal). Peter

3 2

Stanza Ids
by Dave Cridland 17 Oct '24

17 Oct '24

Hi all, I was skimming XEP-0490, and the optimisation of injecting multiple displayed elements into a message referencing different ids in different namespaces made me spit my tea dramatically over my keyboard. Not really, of course - tea is far too precious to waste on such things, but you get the idea. There's clearly no better alternative, because we have clients in the wild which are quite painful about message ids, and will therefore break things if we were to rely on their ids being unique. This got me thinking: What could we do to - if not remove this wart entirely, at least file it down so it was less of a nuisance. (I'm not sure if warts do get filed down; I am not a doctor, do not try this at home) In a perfect world, we might remove XEP-0359 entirely - not because it is, in and of itself, a bad spec, but because it is essentially patching problems elsewhere. So, what can we do to ensure that some tuple of the stanza attributes perhaps (from,id), or possibly (from,to,id), is unique "enough", and stable "enough", for both receivers and senders to rely on without having to inject multiple ids? Is this worth doing - it feels like it would clean up a lot of other constructs, but some cases (MAM, perhaps?) might always need to inject other identifiers. If we were to rely on clients using unique identifers, could this be subverted in some way beneficial to an attacker? My gut feeling is that even if we find that we're stuck with XEP-0359 in all the same cases, we might produce an interesting document about the security implications of the id attribute of stanzas, which feels like a gap worth filling. What do you all think? Dave.

2 1

NEW: XEP-0495 (Happy Eyeballs)
by Daniel Gultsch 17 Oct '24

17 Oct '24

Version 0.1.0 of XEP-0495 (Happy Eyeballs) has been released. 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. Changelog: * Promoted to Experimental (XEP Editor: dg) URL: https://xmpp.org/extensions/xep-0495.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 0

mailing list simplification
by Peter Saint-Andre 16 Oct '24

16 Oct '24

Hi all, The XSF infrastructure team is planning to move our mailman installation from a dedicated machine to a cloud service. In preparation for doing so, I have just deleted three lists that are no longer in use: iot(a)xmpp.org security(a)xmpp.org server-developers(a)xmpp.org If IOT or security topics arise, they can be discussed on this list or in the xsf(a)muc.xmpp.org chatroom. Peter

3 4

Proposed XMPP Extension: Pubsub Node Relationships
by Daniel Gultsch 15 Oct '24

15 Oct '24

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub Node Relationships Abstract: This specification describes how to establish links between pubsub nodes, allowing for optional hierarchical organization. URL: https://xmpp.org/extensions/inbox/pubsub-node-relationships.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

4 4

XMPP Council Agenda 2024-10-15
by Daniel Gultsch 15 Oct '24

15 Oct '24

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, October 15 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-0198 (Stream Management) * Proposed XMPP Extension: Pubsub Node Relationships 4) Items for voting a) Proposed XMPP Extension: Pubsub Node Relationships https://xmpp.org/extensions/inbox/pubsub-node-relationships.html b) Issue Last Call on 'XEP-0490: Message Displayed Synchronization' https://xmpp.org/extensions/xep-0490.html 5) Pending votes * Travis on Happy Eyeballs See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

1 0