Re: [xmpp] Unicode Version Interop Concerns in JIDs

["Sam Whited" <[e-mail]>]

On Fri, Sep 13, 2019, at 07:35, Florian Schmaus wrote:
> 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..dat")

The various Go Unicode libraries do this (more or less). They provide
build options that allow you to pick a Unicode version, so you could
always build with the latest one or possibly link in multiple (I think,
I haven't tried that but I don't see why it wouldn't work).

> 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.

Sort of. Having libraries that link in UCD data or similar makes things
easier, but we still have to decide what's supported, what special cases
need to be worked around (I'm sure there will be some odd bugs and what
not that crop up with different versions), do we do negotiation or
support a specific range of versions, what if you're using an old
version of the XMPP client that doesn't have the new data files shipped
with it or linked in, etc.

I agree Unicode related libraries should support multiple versions, I
just don't think that really solves the problem of how we address
that in the XMPP specs and how we address compatibility between
clients and servers.

—Sam

-- 
Sam Whited