- Standards

XMPP Council Agenda 2024-02-13

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, February 13 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) xep-template: Require accessibility and privacy sections https://github.com/xsf/xeps/pull/1322 b) Issue Last Call on XEP-0360: Nonzas (are not Stanzas) https://xmpp.org/extensions/xep-0360.html c) Proto XEP: XEP-xxxx: MUC Avatars https://xmpp.org/extensions/inbox/muc-avatars.html 5) Pending votes - Dan on starting Start Last Call on XEP-0392: Consistent Color Generation See the all new spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

2 years, 1 month

1
0
0 0

XEP-0440 and tls-server-end-point

by Simon Josefsson

Hi I was reading XEP-0440 and noticed that since 2022-08 it requires support for tls-server-end-point channel bindings. I believe this is unfortunate because tls-server-end-point channel binding are worse than either of tls-unique or tls-exporter. Mandating support for this weak channel binding will detract from efforts to implement the stronger tls-unique and tls-exporter. When deciding what to prioritize, it may be that someone believes that since XEP-0440 requires tls-server-end-point, it is more important to implement it than spend time getting tls-exporter implemented. That would be a bad outcome. I suggest changing XEP-0440 to require tls-unique when TLS <= 1.2 is used and tls-exporter when TLS >= 1.3 is used. If you have already given up on supporting TLS <= 1.2 I think you should only mandate tls-exporter as this is the best available channel binding available. I believe tls-server-end-point is generally best left unimplemented to guide efforts towards supporting the stronger tls-exporter. /Simon

2 years, 2 months

8
11
0 0

Escape characters in XEP-0393: Message Styling

by Werner Kroneman

Hello, first of all, this is my first attempted contribution to an Internet standard, so I do apologize if the form is a bit off. That said, I was implementing a parser for "XEP-0393: Message Styling", and I ran into the issue that not much is defined in the way of escape characters. In Gajim, for instance, the sequence *hello* becomes bold, the sequence \*hello* does not, but the sequence \\*hello* also does not. In many applications, preceding a \ with another \ escapes the latter \, making it so that the escape character itself is escaped, and therefore the * that creates the emphasis span would not be. However, the standard does not mention any rule regarding this (and Gajim does not do what I expect), so it is perhaps a good idea to add a note about this before making it final. Kind regards, Werner

2 years, 2 months

2
1
0 0

UPDATED: XEP-0483 (HTTP Online Meetings)

by kevin.smith＠isode.com

Version 0.2.0 of XEP-0483 (HTTP Online Meetings) has been released. Abstract: This specification defines a protocol extension to request URLs from an external HTTP entity usable to initiate and invite participants to an online meeting. Changelog: * Use XEP-0482 to send the meeting link to another party (do) URL: https://xmpp.org/extensions/xep-0483.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 years, 2 months

1
0
0 0

ACTIVE: XEP-0458 (Community Code of Conduct)

by kevin.smith＠isode.com

Version 1.0.0 of XEP-0458 (Community Code of Conduct) has been released. Abstract: This document describes the XMPP Standard Foundation's Code of Conduct. Changelog: Changed status to Active per Board vote on 2024-01-05. (psa) URL: https://xmpp.org/extensions/xep-0458.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 years, 2 months

1
0
0 0

Re: Proposed XMPP Extension: Reporting Account Affiliations

by Kim Alvefur

On Wed, Jul 19, 2023 at 04:12:22PM +0200, Daniel Gultsch wrote: >Hi Kev, > >council has accepted this XEP. > >cheers >Daniel > >On Tue, Jul 4, 2023 at 3:56 PM <kevin.smith(a)isode.com> wrote: >> >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Reporting Account Affiliations >> Abstract: >> This specification documents a way for an XMPP server to report to >> other entities the relationship it has with a user on its domain. >> >> URL: https://xmpp.org/extensions/inbox/xep-reporting-account- >> affiliations.html >> >> The Council will decide in the next two weeks whether to accept this >> proposal as an official XEP. Bringing Up Matthews ProtoXEP Incidents over the holidays reminded me of this one. -- This friendly reminder brought to you by Zash

2 years, 3 months

1
0
0 0

XSF membership application period Q1 2024

by Alexander Gnauck

Hello, I have setup the membership application Wiki page for the application period Q1 2024 Applications are encouraged from developers and others who are actively involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki: https://wiki.xmpp.org/web/Membership_Applications_Q1_2024 If you don't have a wiki account, send your full name, preferred nickname and email address to me or one of the other Sysops: https://wiki.xmpp.org/web/Sysops Apply now!!! Thanks, Alex

2 years, 3 months

1
0
0 0

Re: Proposed XMPP Extension: HTTP Online Meetings

by Daniel Gultsch

Dear Editor, Council has accepted this XEP. Dear XEP author: Council has noted some overlap with XEP-0482. Please get in touch with the authors of that XEP to see if you can merge and/or remove the overlap. See Marvins earlier mail for details. cheers Daniel

2 years, 3 months

2
1
0 0

XMPP Council Agenda 2023-12-12

by Daniel Gultsch

Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, December 12 2023 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 - UPDATED: XEP-0402 PEP Native Bookmarks - UPDATED: XEP-0458 Community Code of Conduct - UPDATED: XEP-0474 SASL SCRAM Downgrade Protection - NEW: XEP-0483 HTTP Online Meetings (https://xmpp.org/extensions/xep-0483.html) - NEW: XEP-0484 Fast Authentication Streamlining Tokens (https://xmpp.org/extensions/xep-0484.html) - Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All (https://xmpp.org/extensions/inbox/host-meta-2.html) 4) Items for voting a) XEP-0077: Specify account creation via HTTP as non-exclusive alternative to XMPP (https://github.com/xsf/xeps/pull/1299) b) Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All (https://xmpp.org/extensions/inbox/host-meta-2.html) 5) Pending votes none See the all new spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfa… 6) Date of Next 7) AOB 8) Close

2 years, 3 months

1
0
0 0

NEW: XEP-0484 (Fast Authentication Streamlining Tokens)

by kevin.smith＠isode.com

Version 0.1.0 of XEP-0484 (Fast Authentication Streamlining Tokens) has been released. Abstract: This specification defines a token-based method to streamline authentication in XMPP, allowing fully authenticated stream establishment within a single round-trip. Changelog: * Promoted to Experimental. (XEP Editor: kis) URL: https://xmpp.org/extensions/xep-0484.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 years, 3 months

1
0
0 0

2026

2025

2024

2023

Standards