[db-wg] UTF8

On Wed, May 06, 2015 at 02:46:05PM +0200, Job Snijders wrote:

Hi

> On Wed, May 06, 2015 at 02:07:56PM +0200, Piotr Strzyzewski wrote:
> > > correct name? Just for arguments sake, changing my name into Chinese
> > > with Google translate changes the space to a '.'. If that is correct
> > > then the current syntax check fails.
> > 
> > Well spotted.
> 
> The syntax check might need fixing then. The assumption that every name
> consists of at least two strings seperated by a space is based on
> nothing. I would consider this a bug. Who will file the issue on github?
> :-)

Thanks for volunteering. ;-)

> > > There was a Labs article written some time ago on
> > > UTF8 https://labs.ripe.net/Members/kranjbar/internationalisation-of-ripe-database
> > 
> > > This article put forward the idea of keeping all existing attributes
> > > in ASCII (but really meant Latin1) and allowing additional optional
> > > attributes for name and contact details in local language.
> 
> > It was back in 2010 during the RIPE61 when I propose person-idn: and
> > other similar attributes. Although I understand your point of view, I
> > believe that the situation has changed through years.
> 
> So you two are leaning towards allowing UTF8 in some fields, and in
> other places add an optional new attribute (such as person-idn) if
> people want to describe more clearly what their actual name is? 

At first no. The proposal sent few weeks ago was to introduce full
support for UTF8 without any new attributes. Taking into account my old
idea and Denis' point of view, we can make some consensus here. Hope
that other members of the community will also present some views and
ideas here.

> If this is the case it would be good if you go over all
> fields/attributes the database currently knows, and compile a full list
> of attributes that should receive an idn-sibling or should accept UTF8
> instead of whatever they currently accept.

What I see as an options right now are:

1. Full support for UTF8 in current attributes (without primary keys).
2. Full support for UTF8 in complementary attributes (list have to be
made; interim solution).

Option 2 could lead to server behaviour controlled by new option. This
option could control which one of those complementary attributes is
returned (Latin1 or UTF8) by the server. Moreover, the default behaviour
could be changed after some transitory period of time.

Piotr

-- 
gucio -> Piotr Strzyżewski
E-mail: Piotr.Strzyzewski at polsl.pl