January 2025 - Standards

XEP-0001 Changes to reflect current practice wrt XEP Authors

by Dave Cridland

Hey hey, Boring incoming: https://github.com/xsf/xeps/pull/1407 This is draft to avoid the XSF Board accidentally approving it before the community has had a chance to discuss. The main change is the paragraph added in Section 6 (Discussion Process), covering changes to the XEP during Experimental: The XEP author incorporates the feedback by creating source control patches > (such as Pull Requests), in line with the preferred method in &xep0143;. > Direct changes to an Experimental XEP, such as a contributor providing a > patch (or Pull Request on GitHub), are still the responsibility of the XEP > author, and are only applied if the XEP author agrees. If a XEP has > multiple authors, while agreement is sought from all authors, only those > opinions from responsive authors are considered. If the Approving Body > feels that the XEP author is not responsive, another author may be added > unilaterally by the Approving Body. This is trying to do two things: 1) Document the existing practice that the XMPP Council has followed, whereby changes to Experimental XEPs need "agreement" (PR approval, or similar) from the XEP Author. 2) Document the existing practice that the XMPP Council has followed. whereby if a XEP Author isn't responsive (ie, doesn't respond to emails, etc) the XMPP Council can add a new XEP Author. 3) Document the *new practice* that if a contribution isn't a PR, it's the XEP Author who is responsible to turn it into one. The rest of the changes surface and restate existing process/policy/URLs and aren't that interesting (well, even less interesting). There is one additional possible process deviation we should document (or call the Process Police out, or something). Submission of a XEP, as per XEP-0143, occurs via email tot he Editor. Is this really still the case? Or are these now by PR? That'll need changing in XEP-0143, which I'm happy to do if that's the case. It'd be nice to have a non-PR variant of the process (post here?) Dave.

1 month, 2 weeks

6
17
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.

3 months, 1 week

3
3
0 0

LAST CALL: XEP-0484 (Fast Authentication Streamlining Tokens)

by Daniel Gultsch

This message constitutes notice of a Last Call for comments on XEP-0484. Title: Fast Authentication Streamlining Tokens Abstract: This specification defines a token-based method to streamline authentication in XMPP, allowing fully authenticated stream establishment within a single round-trip. URL: https://xmpp.org/extensions/xep-0484.html This Last Call begins today and shall end at the close of business on 2025-01-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!

6 months, 3 weeks

5
15
0 0

LAST CALL: XEP-0424 (Message Retraction)

by Daniel Gultsch

This message constitutes notice of a Last Call for comments on XEP-0424. Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted. URL: https://xmpp.org/extensions/xep-0424.html This Last Call begins today and shall end at the close of business on 2025-01-06. 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!

7 months, 2 weeks

9
26
0 0

UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection)

by Daniel Gultsch

Version 0.4.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been released. Abstract: This specification provides a way to secure the SASL and SASL2 handshakes against method and channel-binding downgrades. Changelog: * Use better value delimiter (tm) URL: https://xmpp.org/extensions/xep-0474.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.

7 months, 3 weeks

1
0
0 0

UPDATED: XEP-0424 (Message Retraction)

by Daniel Gultsch

Version 0.4.2 of XEP-0424 (Message Retraction) has been released. Abstract: This specification defines a method for indicating that a message should be retracted. Changelog: * Use a XEP-0425 /me command in the fallback body * State that a tombstone's <retracted/> element's 'id' attribute should match the retraction message's 'id'. * Specify XEP-0359 as a dependency and require that the stanza 'id' be used instead of the origin-id. * Update the "Security Considerations" to mention the risk of non- unique message IDs. (jcb) URL: https://xmpp.org/extensions/xep-0424.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.

7 months, 3 weeks

1
0
0 0

Proposed XMPP Extension: Gateway Relayed Encryption

by Daniel Gultsch

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Gateway Relayed Encryption Abstract: This specification describes a mechanism for end-to-end encryption with gateways that is compatible with third-party networks. URL: https://xmpp.org/extensions/inbox/gateway-relayed-encryption.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

8 months

5
10
0 0

Media sharing with Metalinks

by Schimon Jehudah

Greetings! I am drafting a post to next Tuesday evening about Metalink. I did a superficial search, and I did not find a mention of Metalink in the XEP index. Metalink is known as standard RFC 5854, and RFC 6249. > Metalink supports listing of multiple partial and full file hashes > along with PGP signatures. It supports listing any URI (i.e. FTP, > Gemini, HTTP, rsync, BitTorrent, eD2k, IPFS, magnet link etc.). It also has a "description" field, which is crucial in messaging system, as it can save the effort of sending an extra message to describe the content. This saves in half the number of messages upon sharing files via messages. See the example Metalink file in the following post. https://portal.mozz.us/gemini/woodpeckersnest.space/~schapps/journal/2024-1… In the example Metalink file, the content is available via BitTorrent, eD2k, FTP, HTTP, and Kad. Handling Metalink would be of benefit to XMPP. Sending of a file: > http://hfu.xmpp.i2p/StealThisFilm.Part1.avi > This is the first part of the movie "Steal This Film I" from 2006. Sending of a Metalink file: > http://hfu.xmpp.i2p/StealThisFilm.Part1.metalink XMPP client parses the Metalink file (StealThisFilm.Part1.metalink), and displays the given description which is found in that file. I advise to create an XEP for handling of Metalinks. I would be greateful to whom who would want to intstruct me. Kind regards, Schimon

8 months

1
1
0 0

STABLE: XEP-0421 (Occupant identifiers for semi-anonymous MUCs)

by Daniel Gultsch

Version 1.0.0 of XEP-0421 (Occupant identifiers for semi-anonymous MUCs) has been released. Abstract: This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of semi-anonymous users. Changelog: Accept as Stable as per Council Vote from 2025-01-14. (XEP Editor (dg)) URL: https://xmpp.org/extensions/xep-0421.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.

8 months, 1 week

1
0
0 0

XMPP Council Agenda 2025-01-14

by Daniel Gultsch

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, January 14 2025 at 16:30 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: GRE Formatter: MIME * Proposed XMPP Extension: GRE Encrypter: OpenPGP * Proposed XMPP Extension: Gateway Relayed Encryption * LAST CALL: XEP-0484 (Fast Authentication Streamlining Tokens) 4) Items for voting a) Proposed XMPP Extension: GRE Formatter: MIME https://xmpp.org/extensions/inbox/gre-formatter-mime.html b) Proposed XMPP Extension: GRE Encrypter: OpenPGP https://xmpp.org/extensions/inbox/gre-encrypter-openpgp.html c) Proposed XMPP Extension: Gateway Relayed Encryption https://xmpp.org/extensions/inbox/gateway-relayed-encryption.html 5) Pending votes * Dan on Move 'XEP-0421 (Anonymous unique occupant identifiers for MUCs)' to stable See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEU… 6) Date of Next 7) AOB

8 months, 1 week

1
0
0 0

2025

2024

2023

Standards January 2025