- Standards

by Dave Cridland

Hi all, Attached is an *unsubmitted* Internet Draft covering SVCB usage for XMPP. Assuming attachments work on this list! Feedback welcome, I intend to submit this one shortly to the IETF. Dave.

2 years, 4 months

4
7
0 0

Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

by kevin.smith＠isode.com

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Host Meta 2 - One Method To Rule Them All Abstract: This document defines an XMPP Extension Protocol for extending XEP-0156 by modifying the JSON Web Host Metadata Link format to support discovering all possible XMPP connection methods, for c2s and s2s URL: https://xmpp.org/extensions/inbox/host-meta-2.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

2 years, 4 months

4
5
0 0

Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

by Travis Burtrum

Hi Fannys! On 12/16/23 04:06, Fannys wrote: > As I said in the @xsf room the problem with this XEP is that the author > is convinced that this is the one answer to everything and assumes a > *lot* of stuff to get there. And besides the title obviously that is > obvious in a few other places. To try to quickly summarize, we need a lot of info to connect to XMPP servers, and need to get it in very specific (secure) ways. I've thought about this a lot over the years, and (very much thanks to your and other's feedback) tried to explain the reason for every decision. I am absolutely not married to one solution, but alternatives need to accomplish the same goals. "I don't like this" isn't helpful without an alternative proposal that can actually be considered. > Specifically: > > > - It calls SRV records as legacy which is a pretty big departure from > the status quo. > > > For the foreseeable future you will need to maintain legacy SRV > records in addition to this file Yes, because this document explicitly deprecates SRV records (while saying they need to be supported for the forseeable future). > - It effectively makes HTTP a hard requirement for all clients and > servers on the network raising complexity significantly. HTTPS already is a hard requirement, with POSH, with HTTP Upload which is currently the only way to share files in MUCs and with multiple clients / offline clients, and, for most servers, the way they get certificates from letsencrypt. HTTPS is also a well established, fully open protocol with many independent implementations exactly like XMPP, I see no reason to avoid it. XMPP relies on many other standards, just as good or bad (depending on your POV), like DNS, IP, TCP, TLS, XML etc etc. > - Recommends that everything runs through port 443 which is in itself > questionable for this. Because it's most likely to work through real-world firewalls in real-world networks, what's questionable about this? > - Also it introduces a hard requirement for a JSON parser in all clients > and servers which is another point that raises complexity. Again, a JSON parser is already a hard requirement due to POSH. I addressed further reasons I thought this was the best choice in the Rationale https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-hm-json , but, this is not an absolute hill for me to die on. If the consensus is that XML is better here, I'm not opposed, but then it should be the XMPP-subset of XML so that we can actually use the same parser, and don't introduce the real security risk of requiring an XML parser that can parse not-XMPP-XML (just one real world example of this vulnerability in the wild is https://prosody.im/security/advisory_20220113/ ). Please note this would introduce the following (imho, downsides): 1. we could not use host-meta.xml as that requires a not-XMPP-subset-XML parser supporting comments etc etc 2. that means an extra https request when trying to fetch host-meta-2 along with legacy methods 3. so it'd require a new document definition, for a quick reference, it would look very similar to HACX https://xmpp.org/extensions/inbox/hacx.html#example-1 > And I think the discussion about these items individually should have > happened before. Especially since from the discussion in @xsf it seems > that some of the alternatives like DNS were rejected on subjective > opinions of the author. I actually discussed this in xsf@ 21 months!!!! (damn I'm slow...) before submitting this ProtoXEP https://logs.xmpp.org/xsf/2022-03-17#2022-03-17-ead56d61d395a6b9 I hopefully explained my rationale re: DNS well https://www.moparisthebest.com/xeps/host-meta-2.html#rationale-dns but please if you disagree and/or have alternatives do share. > My opinion is that HTTP and JSON shouldn't be requirements and i don't > plan to use this XEP anywhere even if it gets voted in. We already have > problems with ports and everything assuming HTTP and I don't want the > problem to be worse. Plus I don't want the complexity at all. So to summarize my current thoughts: * I think HTTPS is likely to be a hard requirement for this, at least I can't think of an alternative that can accomplish the same goals * JSON is *not* a hard requirement, and could be replaced, but has the downsides I layed out above and in the rationale > Fannys I very much appreciate the detailed feedback, thank you!

2 years, 4 months

1
0
0 0

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, 4 months

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, 4 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, 5 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, 5 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, 5 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, 5 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, 6 months

1
0
0 0

2026

2025

2024

2023

Standards