Re: [xmpp] Unicode Version Interop Concerns in JIDs

[Florian Schmaus <[e-mail]>]

On 10.09.19 16:38, Ralph Meijer wrote:
> Now another user comes along, using a server that supports Unicode 6.3.
> Since BACON wasn't defined before Unicode 9, its code point is
> unassigned. When receiving presence from the other user, what should the
> receiving server do?


There is a fourth option/solution:

       agility regarding the supported Unicode standard.

PRECIS libraries typically use the Unicode/Character predicate and
property retrieval functions (.e.g., isISOControl(),
getDirectionality(), …) from their runtime environment. For example the
java.lang.Character API.

The problem is that most runtimes only update their supported Unicode
version with new (major) runtime release (e.g., Java 9). The key
observation here is: to support a new version of the Unicode standard,
no API changes or changes of the PRECIS library are necessary. What
changes is usually that a code point transitions from unassigned to
assigned, and so do its properties, and hence the return values of that
Unicode predicate and property retrieval functions.

So it would be great if runtimes would provide a way to load a new
Unicode Character Database [1] without updating the runtime environment.
Something like Character.loadUnicodeDb("unicode-12.1.0.dat")

Now I know that we may not have not much control over what functionality
runtime environments provide. However, nothing prevents you from using
(or implementing) a Unicode library with that such feature. I am
considering implementing something like that in [2]. The whole process
could eventually be automated, which, I believe, is solving the issue
Ralph describes.

- Florian

1: http://www.unicode.org/reports/tr44/tr44-24.html
2: https://bitbucket.org/sco0ter/precis