XSF Discussion - 2023-08-25

Is RFC 5122 used for non ascii adresses? I see RFC 8266 but that is the one that uses PRECIS so I am guessing its not right?

or wait is it the unicode is specified in core

PRECIS is the official standard, but many implementations are still hanging in nodeprep land

yeah i remember that. so RFC 8266 is the one for PRECIS if we ever adopted i guess

the funny thing is: there is no signalling, and PRECIS is a moving target due to Unicode consortium adding new characters to the classes every year

signaling in xmpp you mean? for PRECIS support

So I am guessing then we are using the unicode specified in core

MSavoritias fae.ve: signalling for PRECIS/nodeprep and the accepted unicode version.

right

I used to join some rooms with the nickname 🤖 and it was hilarious, because it made remote servers kick their clients out of the room due to JID malforming

(only for certain definitions of "hilarious", obviously)

Is Matrix there to lead to the XMPP? Or do we want normies to use matrix instead?

Would it be possible to also advertise it? À la inbox/SLA?

In stream:features

nonono, wrong channel?

You can go troll elsewhere

also we dont do normies here

so am I right in thinking its basically a case of: Core says Unicode and then we follow what prosody/ejabberd do?

ah wait standard point to unicode 6.0 specifically

ok

yes wrong channel. don't answer trolls, don't call people normies here.

but why dont we add the signaling at least? I know its hard to upgrade unicode version. But we can at least add the signaling

since we are going to use it anyway

What does signalling help?

because even if magically upgrade to precis and newer unicode, unicode and precis keep changing

As far as I can see, either you have to flag day, or you're stuck on stringprep forever, so we're stuck on stringprep forever.

so pointing to what the server supports helps at least see what the network supports no?

> because even if magically upgrade to precis and newer unicode, unicode and precis keep changing That's answering a different question, though, that's answering "Why can't we mix unicode versions", not "what can we do with signalling".

MSavoritias fae.ve: the problem is that technically, this is a stream property, but in a typical c2c situation, you have three streams, and with MUC you have four streams.

so the question would be: where do you add the signal?

> MSavoritias fae.ve: the problem is that technically, this is a stream property, but in a typical c2c situation, you have three streams, and with MUC you have four streams. Four for C2C too :)

heh. point taken

its a headache all around

Kev: we've managed to ban GC1.0, we can manage an eventual transition to unicode 15.0 if we add signalling now

ah i like an optimist :D i agree its possible to move at some point

but yeah i would think signalling is a requirment before we do anything

IIRC the last time we were dead-ended at the question _where_ the signal needs to be attached

naively, it sounds like perfectly placed in a stream feature, but you can't communicate stream features to the client for s2s

But you also can't do much with the information, even in the client. You can't somehow change your JID to not include things allowed by that particular version of unicode within precis because you're talking to a server that's on an older version.

I could see it as an item in disco#info, which is probably good enough for querying your server, a remote domain or a remote MUC service.

Kev, you could downgrade if you knew the other server didn't support as higher as you do :/

How, though?

Your JID is your JID, you can't change it just because someone else is on an older unicode.

I guess you can in the limited case of resource setting, but not the general case.

Kev: when joining a room, the client can restrict valid nicknames based on the remote domain's features. A server sending from an "invalid" JID to a remote server could use some mapping algorithm to make the JID look valid on the remote side

XEP-0106 surely can be plugged in here.

if we mandate that as part of the precis-signal, clients can automatically discover and un-escape

So before you share your JID with someone, you need to know what server they're on, so you can work out which NAT your server is going to need to perform to talk to them?

We cant escape that though can we? Even if we magically upgrade tomorrow everybody and everything. there is a new unicode version every year so we need negotiation and graceful degration of jids

so I basically implement 8266 with PRECIS right?

Kev: the good thing is that their client will automatically apply the escaping when connecting to an old server :P

for newest Unicode

to come back to my original question

So we're assuming that all clients will be at least as new as all servers, then :p

Kev: that said, I don't see any drawbacks for adding signalling, and after that we can talk about allowing a wider range of JID characters.

I'm sure there are better options out there than closing c2s connections on "invalid" JIDs

> So we're assuming that all clients will be at least as new as all servers, then :p No. We are assuming that some servers support newer unicode than others. hence the signalling :) Otherwise you might as well through jids until you are not denied :)

i'd suggest that rfc target utf-8 rather than unicode but then theres another class of issues with different security risks

although if rfc 5122 doesnt address unprintable/lookalike characters then ignore that last part, utf-8 validation would suffice

(and the xml parser may as well handle that, at that point)

we already have validation in PRECIS though

I'm not sure if there's any server implementation that supports PRECIS.

Could data forms be replaced with XHTML?

Because it says in the XEP that is used as a basic Forms alternative

"No", is the short answer, but there may be specific cases where they could. Why?

was just curious why we need a specific thing instead of just using XHTML directly

because its yet *another* xep

MSavoritias fae.ve: Yet another XEP that attempts to do one thing and do it well is the name of the game here ;)

thats exactly what i was thinking. XForms

heh. I dont like Unix so I may be biased here :P

I think it's history again. If xforms had really gone and been used at the time probably data forms would exist. But now xforms is basically unused by anyone anywhere and data forms is the basis for half of all XMPP features ✏

I think it's history again. If xforms had really gone and been used at the time probably data forms wouldn't exist. But now xforms is basically unused by anyone anywhere and data forms is the basis for half of all XMPP features ✏

wait can i see what xeps depend on data forms xep?

somehow

Hmm. Unsure

yeah looking at https://data.xmpp.net/explore/xmpp/xeps

i dont see anything obvious

Since service discovery uses data forms it's indirectly everything from a certain PoV ;)

like options for depedencies

MSavoritias fae.ve, XEPs should put <spec>XEP-0004</spec> in their /xep/header/dependencies but probably not all of them are doing it.

And probably people put 30 in there without mentioning that 30 needs 4.

You could grep for jabber:x:data and add this dependency to every XEP which actually uses it.

Kev, ugh, XEP-0030 doesn’t even mention XEP-0004 as a dependency…

yeah it doesnt

Kev, MSavoritias fae.ve, it is actually XEP-0128 we were thinking of.

Fair enough.

ah so 30 supports without data forms. nice

works*

MSavoritias fae.ve, XEP-0030 only defines disco#items and disco#info, and XEP-0128 adds data forms extensions in disco#info.

noted

Prior art for adding stuff to arbitrary elements :)

> we already have validation in PRECIS though ok now i see what it is, https://datatracker.ietf.org/group/precis/documents/ wikipedia was giving some entirely different shit for PRECIS

nice name clash