XSF Discussion - 2019-09-13

flow, I don’t see how your solution suggested on xmpp@ietf is practical. 1. "let’s change all the existing unicode interface implementations!" does not seem practical to begin with 2. it still leaves the issue of software not being on the same version all the time across the internet, and updating the unicode database is a *breaking* update [1], so it won’t happen e.g. on debian [1]: https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade.html

jonas’, I did not suggest to change all existing unicode interface implementation, nor to perform it system wide. The point is, I could take CSH's precis library, add a feature which allows to (dynamically) load a new Unicode Character Database (UCD) and be done. Yes, probably not everyone will always be on the same Unicode Version, but there is not much you can do about it, besides reducing the amount of services which are not on the same unicode version. And increasing agility regarding the supported unicode standard helps here

yes to my understanding this is the benefit of precis. you can just ship a new unicode database with a minor update of the app. you don’t have to write new code

that should be as easy as increasing a build dependency somewhere (or something)

let’s load the unicode database from the xmpp server

so one could hope that proliferation of new databases goes rather fix

well, at least the only implementation of Precis I know for python it just uses the db shipped with python

well if we identify that early as a pontential source of problems we could hand out implementation notes that say please make it pluggable

true

jonas’, i actually pondered about putting the unicode database into dns as PoC. It may be not suited for clients, due privacy reasons, but maybe for servers. And it's fun ;)

flow, I agree that your proposal would be an improvement, but like others, I see it as a mitigation given the circumstances rather than an outright solution.

dwd, point of view i guess, I don't think there is a solution which does not involve agility of the supported unicode standard, so I see agility as a solution

but happy to be proven wrong

flow, I think we have to be aiming for what you're suggesting. I do not think it'll solve things, just lessen their occurence.

https://github.com/byllyfish/precis_i18n/issues/8

let’s see how they react :)

jonas’, I suspect it's a matter of having unicodedata able to dynamically load.

dwd, that’s what I’m asking for, ain’t I?

jonas’, I mean, in the standard Python library, not so much in precis_i18n.

dwd, python uses it for parsing, so I doubt that’s happening

(I think)

having unicodedata load dynamically in a separate object (like you can instantiate separate `random` objects) would be a measure of course

Daniel, you have a working prototype for MIX? Is it using :core:0 or :core:1 for joining? MIX-PAM uses :core:0, but MIX-CORE uses :core:1 :(

haven’t notice that. i seem to be using core:0 and pam:0

nice, it’s pam:1 in the spec though

and it was working with the one and only server implementation

it has been 3/4 year though since i tested things

dwd: I'm curious if we could something with service discovery and/or stream features.

ralphm, Possibly. But - taking "schloß@example.org" for a moment - if we assume that the caonical form is decided by "example.org", then a local user might type "schloss@example.org", and at some point we ask example.org what the correct version is. At that point, do we need heavyweight canonicalisation on other servers? (We might do - I'm just exploring).

Dear lazyxmpp, I wish for a PRECIS implementation suitable for use in C

Did the normalization of ß change between Unicode versions?

that response on the ietf mailing list, i believe, misses the point. this is a security issue of denial-of-service, not just compatibility

Indeed Nameless RTL Person.

Should we adopt U+061C instead of the speech bubbles? 🙂

Or maybe U+00DF

Zash: U+FFFD was also suggested.

(btw, U+061C was the first character that I could find to have an empty nickname. some other ones were already blocked when i tried)

so it's not that bad ^^

Space characters that are in Unicode 3,2 (or whatever stringprep uses) would be normalized to U+20 and then the nickname is forbidden if that's all there is

Space-ish codepoints outside of that tho

Well, sure. That's why PRECIS came about

well, a nickname that looks empty

At least it doesn't crash iPhones

Nice one jonas’ : > it is required that users of PRECIS have precise control over the unicode database version used.

precisely

what a precious comment

oh my god, I didn’t even notice

suuure :D

Nice one