Re: Unicode Version Interop Concerns in JIDs

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============0789146513811329167==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="FUPHomxaR6T9J7DQf5qS3sge3xV4GeCYc"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FUPHomxaR6T9J7DQf5qS3sge3xV4GeCYc
Content-Type: multipart/mixed; boundary="cSYIVEMJlLnn1Pkgmyhpj1mnXiD1zS3iG";
 protected-headers="v1"
From: Florian Schmaus <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: Re: [xmpp] Unicode Version Interop Concerns in JIDs
References: <[email protected]>
In-Reply-To: <[email protected]>

--cSYIVEMJlLnn1Pkgmyhpj1mnXiD1zS3iG
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable

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 th=
e
> 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(), =E2=80=A6) from their runtime environment. For examp=
le 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


--cSYIVEMJlLnn1Pkgmyhpj1mnXiD1zS3iG--

--FUPHomxaR6T9J7DQf5qS3sge3xV4GeCYc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl17RtJfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3
NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF
IFIUPQf+MqiL0HKSSd6rS2feAeX3vPc7WnGvVLRZeJngbwknw+KSkf2XS7Okwpxm
XXTqH3S0PoWJyQjEihLaTmWqejylMYGA0bsT9rwE9L3xT3ZxXhygr6sKGupPPMVX
npPJZiYc/56Oi7hlM38iEGyEXXuUYC/nkdpTveIPIxoimRQ6pCYcnF7s0u/phP99
4Un1upyiM+iXJuT6HyggDUiTDVhnDm1r1yG116T+A+jyKuaFIFgqWUtByDUXz3SD
XumGtCOhjevT4lP+SRNs9FD0S4OfCgIV6LVsTFlQwbfVmNygAohs2lAR/a67rBRx
rRuDAZMECOz7UitS1ZF7iHHTxPZpUA==
=Kg0N
-----END PGP SIGNATURE-----

--FUPHomxaR6T9J7DQf5qS3sge3xV4GeCYc--


--===============0789146513811329167==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp

--===============0789146513811329167==--