XSF Discussion - 2023-02-01

I've sent a message to the jdev list two hours ago, but it doesn't show up in the archive, nor did it bounce. Did it get stuck in a spam filter on the server?

I recieved it

The one about moving .work? I got it

Ok tx

Turns out that emails sent in February do not tend to end up in January's archive.

Oh. Golly.

(which, in my defense, was the last archive that was displayed when I started to refresh that page)

(which is a poor defense, yes)

(202)3-2-1 !

🚹.on.some.domain.example.net should be a valid domain part of a JID, correct?

Tobi, is it a valid DNS name? ✏

if the answer is 'yes', then it should be also a valid domainpart

given that 🚹 is punycode convertible, I suspect it is a valid DNS name

that what my hunch as well. I didn't find a good online validator, only punycode converters that didn't go boom

ta

According to which combination of normalization RFCs?

I don't think there is much normalization required there

Prosody (STRINGPREP + IDNA2008) says "yes, but actually no"

https://www.rfc-editor.org/rfc/rfc7622 refers to https://www.rfc-editor.org/rfc/rfc5890

what do you mean by yes but no

"Be strict in what you produce yourself, but relaxed in what you allow from others"

Seems to be stringprep/nameprep that disallows it

I wonder if this is because U+1F6B9 was unassigned at the time RFC 5892 was written ✏

Most likely, that's what our 'strict' flag does, rejects unassigned characters or allows them.

well it is not longer unassigned

If you punycode it it would be valid and safer

STRINGPREP is fixed to Unicode 3.2, your argument is invalid

and IDNA2008 sounds like it has something to do with 2008 as well ;)

So I am looking at the DNS RFC for a statement that says "codepoints in the category "Other Symbol (So)" are allowed in U-labels"

No IDNA2008 seems to be fine with it

Slightly related, do you know any XMPP implementation that's using PRECIS for validation?

IIRC there are Python and Rust (library) availability, no idea what uses it. Do people put this in their DOAPs?

Strictly speaking XML 1.0 depends on Unicode 2.0, so yeah.

Tobi, babbler uses https://github.com/sco0ter/precis

Ta

Tobi, I begin to get the impression that 🚹 is not valid in DNS names

mostly because I can't find a rule that "Symbol Other" codepoints are allowed

so even though the codepoint is no longer unassigned, it appears to fall into the default case of the algo shown in https://www.rfc-editor.org/rfc/rfc5892#section-3

Also, are you really sure you want this?

How do you type that?

<ComposeKey> M E N S Y M

it's a good question, but unrelated to the question if the spec allows it

but luckily it appears that the answer to both questions is "no" ✏

no, I don't want it. and no, the spec does not allow it

Flow, true....nobody wants to sell me a domain with 🚹 in it.

is what I currently assume to be the case

the ultimate test :) ✏

each TLD has their own rules for what characters are allowed

Zash, but I assume they only get stricter?

Well allowing characters disallowed by something else would be weird.

and not the "good weired" kind

Even if the your registrar doesn't allow it on their own domain labels, you can still do whatever you like in your own zone.