- Standards

Accepted XEP-xxxx MUC Avatars into historical track

by Daniel Gultsch

Dear Editor, please note that council has accepted the proposed XEP 'MUC Avatars' into the historical track. (A previous submission into standards track has been rejected by the council at that time) https://xmpp.org/extensions/inbox/muc-avatars.html cheers Daniel

1 year, 11 months

1
0
0 0

Feedback requested: SVCB for XMPP

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.

1 year, 11 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.

1 year, 11 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!

1 year, 11 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

1 year, 11 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

1 year, 11 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
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

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

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

1
0
0 0

2026

2025

2024

2023

Standards