Hi Nick
"would it be possible to work towards a day in the future when the ripedb could
formally support utf8 across multiple different field
types, not just email addresses?"
The technical aspect of utilising utf-8 in the RIPE Database has been looked at
several times by the RIPE NCC, but it never moves forward because of the
social/political/registry/legal issues which cannot be resolved at the
technical level:
-Should we allow all/some/none of the data content to be in non Latin
characters?-Is there some data content that must be in Latin characters (for
the correct functioning of the registry?), some that can be duplicated in Latin
and local characters, some that can be in any format chosen by the resource
holder?-If some data is duplicated how will the duplicate sets of data be
verified as a consistent set (does it need to be the same data)?-Who needs to
be able to interpret which parts of the data content and for what purpose?-Who
can make these decisions (this is the bit that has been missing ever since the
subject of utf-8 was first raised many years ago)?
Probably puny code can be implemented for IDNs in a matter of weeks, full
implementation of utf-8 may take years.
cheersdenis
co-chair DB-WG
On Tuesday, 7 July 2020, 23:54:13 CEST, Nick Hilliard via db-wg
<[email protected]> wrote:
Gert Doering via db-wg wrote on 07/07/2020 16:21:
> On Tue, Jul 07, 2020 at 05:03:01PM +0200, Benedikt Neuffer wrote:
>> I think at the moment it would be easier to update the clients to
>> convert punycode in whatever encoding you prefer.
>
> Cementing this abomination even more...
No-one likes punycode.
Do you have a better suggestion? Would raw utf8 work here? How much
would it break? If there were broader support in the ripedb codebase
for utf8, would it be possible to work towards a day in the future when
the ripedb could formally support utf8 across multiple different field
types, not just email addresses?
Nick
