You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Database Working Group

Threaded
Collapse

[db-wg] NWI-11 Internationalised Domain Names

ripedenis@yahoo.co.uk

2020-06-22 22:49:55 CET

Colleagues
There has been some discussion recently and many times over the years about addressing this issue. The chairs believe there has been enough support shown to move forward with this. We would therefore like to present this as 'NWI-11 Internationalised Domain Names'. We propose a problem statement based on the text provided recently by Leo Vegoda, as shown below.
The RIPE NCC has a proposal for a solution to this problem using punycode. We would like to ask the RIPE NCC to present this proposal to the working group. If anyone has any other proposals for a solution, we welcome a discussion on this matter.
cheersdenis
co-chair DB-WG

Problem Statement
The RIPE NCC service region includes countries whose language is not written using Latin script. Many of the languages used in the RIPE NCC service region are written in Latin script but use diacritical marks that fall outside the US-ASCII character set. Internationalized Domain Names (IDNs) support the use of these scripts in DNS.
ICANN began delegating IDN Top-Level Domains as part of a test program in 2007 and the IETF updated the IDNA protocol in 2008 and as of mid 2020, there were over 160 IDN TLDs in the root zone.
The IETF published eight standards track RFCs on using IDNs in e-mail in 2012 and 2013. It is reasonable that organizations communicating with people whose preferred script is not Latin-based would want to use an IDN domain for e-mail as well as a web presence. It is also likely that the registry for an IDN TLD would want to use that TLD for its e-mail addresses.
RFC 3912 explicitly notes that the WHOIS protocol has not been internationalized while recognizing that some servers attempt to do so. RDAP has been deployed by the RIPE NCC and explicitly supports internationalization by UTF-8 encoding all queries and responses.
The RIPE community could decide to ignore EAI by trying to require organizations to deploy a secondary e-mail address for use in the RIPE Database. This would reduce the effectiveness of the RIPE Database as the secondary address is less likely to be monitored and used, and so be ineffective.

User Image

Ed Shryane

2020-06-26 16:55:03 CET

RIPE NCC staff member

Dear Working Group,

I'd like to propose the following Solution Definition for NWI-11.

Introduction

Currently, the RIPE database supports email addresses encoded in the Latin-1 character set. However an email address can have an Internationalised Domain Name (IDN), with characters outside Latin-1 (i.e. Unicode). This causes interoperability problems as non-ASCII characters in an email address may not be accepted by a mail server, and only a small subset of Unicode characters can be encoded as Latin-1.

Solution Definition

In order to support Internationalised Domain Names (IDN) in an email address in the RIPE database, I propose to automatically encode email addresses in the Punycode format. Punycode (as defined in RFC 3492) is a way to encode strings containing Unicode characters, such as internationalised domain name (IDN) domains, into ASCII. 

When updating the RIPE database, it is already possible to submit a Punycode encoded value (i.e. with ASCII encoding) for an email address value, but this change automates the conversion of any non-ASCII encoded email address to Punycode.

This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).

Automatic Punycode encoding will only be applied to the domain part of the email address. The local part of the address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.

When querying the RIPE database, any Punycode encoded email address is returned in Punycode (i.e it is not decoded).

I welcome feedback from the community on this proposal.

Regards
Ed Shryane
RIPE NCC


> On 22 Jun 2020, at 22:49, ripedenis--- via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> 
> Colleagues
> 
> There has been some discussion recently and many times over the years about addressing this issue. The chairs believe there has been enough support shown to move forward with this. We would therefore like to present this as 'NWI-11 Internationalised Domain Names'. We propose a problem statement based on the text provided recently by Leo Vegoda, as shown below.
> 
> The RIPE NCC has a proposal for a solution to this problem using punycode. We would like to ask the RIPE NCC to present this proposal to the working group. If anyone has any other proposals for a solution, we welcome a discussion on this matter.
> 
> cheers
> denis
> 
> co-chair DB-WG
> 
> 
> Problem Statement
> 
> The RIPE NCC service region includes countries whose language is not written using Latin script. Many of the languages used in the RIPE NCC service region are written in Latin script but use diacritical marks that fall outside the US-ASCII character set. Internationalized Domain Names (IDNs) support the use of these scripts in DNS.
> 
> ICANN began delegating IDN Top-Level Domains as part of a test program in 2007 and the IETF updated the IDNA protocol in 2008 and as of mid 2020, there were over 160 IDN TLDs in the root zone.
> 
> The IETF published eight standards track RFCs on using IDNs in e-mail in 2012 and 2013. It is reasonable that organizations communicating with people whose preferred script is not Latin-based would want to use an IDN domain for e-mail as well as a web presence. It is also likely that the registry for an IDN TLD would want to use that TLD for its e-mail addresses.
> 
> RFC 3912 explicitly notes that the WHOIS protocol has not been internationalized while recognizing that some servers attempt to do so. RDAP has been deployed by the RIPE NCC and explicitly supports internationalization by UTF-8 encoding all queries and responses.
> 
> The RIPE community could decide to ignore EAI by trying to require organizations to deploy a secondary e-mail address for use in the RIPE Database. This would reduce the effectiveness of the RIPE Database as the secondary address is less likely to be monitored and used, and so be ineffective.
> 
> 

User Image

Leo Vegoda

2020-06-26 18:54:31 CET

Hi Ed,

On Fri, Jun 26, 2020 at 7:55 AM Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:

[...]

> I welcome feedback from the community on this proposal.

>From my personal perspective, this is a welcome first step on the road
towards strong internationalization support in the RIPE Database. It
also seems like a conservative deployment that has a low probability
of causing interoperability problems for automatic systems that query
the database to obtain contact information. Thank you.

Kind regards,

Leo Vegoda

Nick Hilliard

2020-06-27 17:49:20 CET

Leo Vegoda via db-wg wrote on 26/06/2020 17:54:
>  From my personal perspective, this is a welcome first step on the road
> towards strong internationalization support in the RIPE Database. It
> also seems like a conservative deployment that has a low probability
> of causing interoperability problems for automatic systems that query
> the database to obtain contact information. Thank you.

looks reasonable.

Nick

ripedenis@yahoo.co.uk

2020-07-07 13:14:20 CET

 Colleagues
Does anyone have any further comments on this proposal from the RIPE NCC? If there are no objections or alternative suggestions then we can ask the RIPE NCC to implement this proposal.
cheersdenis
co-chair DB-WG

    On Friday, 26 June 2020, 16:55:04 CEST, Edward Shryane <eshryane _at_ ripe _dot_ net> wrote:  
 
 Dear Working Group,
I'd like to propose the following Solution Definition for NWI-11.
Introduction
Currently, the RIPE database supports email addresses encoded in the Latin-1 character set. However an email address can have an Internationalised Domain Name (IDN), with characters outside Latin-1 (i.e. Unicode). This causes interoperability problems as non-ASCII characters in an email address may not be accepted by a mail server, and only a small subset of Unicode characters can be encoded as Latin-1.
Solution Definition
In order to support Internationalised Domain Names (IDN) in an email address in the RIPE database, I propose to automatically encode email addresses in the Punycode format. Punycode (as defined in RFC 3492) is a way to encode strings containing Unicode characters, such as internationalised domain name (IDN) domains, into ASCII. 
When updating the RIPE database, it is already possible to submit a Punycode encoded value (i.e. with ASCII encoding) for an email address value, but this change automates the conversion of any non-ASCII encoded email address to Punycode.
This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).
Automatic Punycode encoding will only be applied to the domain part of the email address. The local part of the address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
When querying the RIPE database, any Punycode encoded email address is returned in Punycode (i.e it is not decoded).
I welcome feedback from the community on this proposal.
RegardsEd ShryaneRIPE NCC


On 22 Jun 2020, at 22:49, ripedenis--- via db-wg <db-wg _at_ ripe _dot_ net> wrote:
Colleagues
There has been some discussion recently and many times over the years about addressing this issue. The chairs believe there has been enough support shown to move forward with this. We would therefore like to present this as 'NWI-11 Internationalised Domain Names'. We propose a problem statement based on the text provided recently by Leo Vegoda, as shown below.
The RIPE NCC has a proposal for a solution to this problem using punycode. We would like to ask the RIPE NCC to present this proposal to the working group. If anyone has any other proposals for a solution, we welcome a discussion on this matter.
cheersdenis
co-chair DB-WG

Problem Statement
The RIPE NCC service region includes countries whose language is not written using Latin script. Many of the languages used in the RIPE NCC service region are written in Latin script but use diacritical marks that fall outside the US-ASCII character set. Internationalized Domain Names (IDNs) support the use of these scripts in DNS.
ICANN began delegating IDN Top-Level Domains as part of a test program in 2007 and the IETF updated the IDNA protocol in 2008 and as of mid 2020, there were over 160 IDN TLDs in the root zone.
The IETF published eight standards track RFCs on using IDNs in e-mail in 2012 and 2013. It is reasonable that organizations communicating with people whose preferred script is not Latin-based would want to use an IDN domain for e-mail as well as a web presence. It is also likely that the registry for an IDN TLD would want to use that TLD for its e-mail addresses.
RFC 3912 explicitly notes that the WHOIS protocol has not been internationalized while recognizing that some servers attempt to do so. RDAP has been deployed by the RIPE NCC and explicitly supports internationalization by UTF-8 encoding all queries and responses.
The RIPE community could decide to ignore EAI by trying to require organizations to deploy a secondary e-mail address for use in the RIPE Database. This would reduce the effectiveness of the RIPE Database as the secondary address is less likely to be monitored and used, and so be ineffective.



  

Benedikt Neuffer

2020-07-07 14:53:47 CET

Hi,

I don't get it. Does the RIPE DB prevent the usage of punycode?

Can someone give me an example, where punycode doesn't work or why
punycode isn't good enough?

Regards,
Benedikt

On 22.06.20 22:49, ripedenis--- via db-wg wrote:
> Colleagues
> 
> There has been some discussion recently and many times over the years
> about addressing this issue. The chairs believe there has been enough
> support shown to move forward with this. We would therefore like to
> present this as 'NWI-11 Internationalised Domain Names'. We propose a
> problem statement based on the text provided recently by Leo Vegoda, as
> shown below.
> 
> The RIPE NCC has a proposal for a solution to this problem using
> punycode. We would like to ask the RIPE NCC to present this proposal to
> the working group. If anyone has any other proposals for a solution, we
> welcome a discussion on this matter.
> 
> cheers
> denis
> 
> co-chair DB-WG
> 
> 
> Problem Statement
> 
> The RIPE NCC service region includes countries whose language is not
> written using Latin script. Many of the languages used in the RIPE NCC
> service region are written in Latin script but use diacritical marks
> that fall outside the US-ASCII character set. Internationalized Domain
> Names (IDNs) support the use of these scripts in DNS.
> 
> ICANN began delegating IDN Top-Level Domains as part of a test program
> in 2007 and the IETF updated the IDNA protocol in 2008 and as of mid
> 2020, there were over 160 IDN TLDs in the root zone.
> 
> The IETF published eight standards track RFCs on using IDNs in e-mail in
> 2012 and 2013. It is reasonable that organizations communicating with
> people whose preferred script is not Latin-based would want to use an
> IDN domain for e-mail as well as a web presence. It is also likely that
> the registry for an IDN TLD would want to use that TLD for its e-mail
> addresses.
> 
> RFC 3912 explicitly notes that the WHOIS protocol has not been
> internationalized while recognizing that some servers attempt to do so.
> RDAP has been deployed by the RIPE NCC and explicitly supports
> internationalization by UTF-8 encoding all queries and responses.
> 
> The RIPE community could decide to ignore EAI by trying to require
> organizations to deploy a secondary e-mail address for use in the RIPE
> Database. This would reduce the effectiveness of the RIPE Database as
> the secondary address is less likely to be monitored and used, and so be
> ineffective.
> 
> 


User Image

Gert Doering

2020-07-07 15:03:46 CET

Hi,

On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote:
> I don't get it. Does the RIPE DB prevent the usage of punycode?
> 
> Can someone give me an example, where punycode doesn't work or why
> punycode isn't good enough?

From what I understand, the intent is to convert incoming e-mail:
attributes in "non-punycode format" to punycode before storing in the DB.

I do not have a very strong opinion on this proposed implementation.


In the long run, I think punycode is a horrible, horrible hack and must
die in flames.  So if we can have a proper database with proper charset
support, my surname would appreciate.

And yes, this will most likely involve UTF-8 internally and export filters
(I do not want to see UTF-8, ever, if I can have ISO8859-15 instead - yeah,
come, sue me)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Ed Shryane

2020-07-07 15:20:46 CET

RIPE NCC staff member

Hello Gert, Benedikt,

> On 7 Jul 2020, at 15:03, Gert Doering via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> 
> Hi,
> 
> On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote:
>> I don't get it. Does the RIPE DB prevent the usage of punycode?
>> 
>> Can someone give me an example, where punycode doesn't work or why
>> punycode isn't good enough?
> 
> From what I understand, the intent is to convert incoming e-mail:
> attributes in "non-punycode format" to punycode before storing in the DB.
> 

You are correct. 

From my Solution Definition:

"When updating the RIPE database, it is already possible to submit a Punycode encoded value (i.e. with ASCII encoding) for an email address value, but this change automates the conversion of any non-ASCII encoded email address to Punycode."

This automated conversion will allow any email address with an IDN (non-ASCII) domain name to be stored as Punycode.

Regards
Ed Shryane
RIPE NCC


User Image

Elad Cohen

2020-07-07 16:26:15 CET

Hello,

I would like to suggest an improvement:

In the whois database backend, each textual attribute (last name, etc) can have an additional column and in that column the punycode-representation of the attribute value can be written.

The punycode-representation can be added in the related column only if there was at least a single non-ascii character in the textual value that was inputted by the user, otherwise it will be empty.

The punycode-representation can be in the format of [FIELD-NAME]--[punycode-ascii-characters] instead of xn--[punycode-ascii-characters], in order to avoid duplication with textual strings that starts with "xn--".

There shouldn't be "punycode representation" columns in the database for email-related fields, nor for object-reference fields.

Using the above, old protocols will still be able to interact with the database as they are now, no ground up development of the whole backend will be needed to support internationalization, the new "punycode-representation" columns encoding is similar to the encoding of the current columns, end-users will be able to use their internationalized names and other internationalized textual strings, RIPE NCC will be able to display internationalized strings online and through supported-services.

Regards,
Elad


________________________________
From: db-wg on behalf of Edward Shryane via db-wg
Sent: Friday, June 26, 2020 5:55 PM
To: db-wg
Cc: ripedenis _at_ yahoo.co _dot_ uk
Subject: Re: [db-wg] NWI-11 Internationalised Domain Names

Dear Working Group,

I'd like to propose the following Solution Definition for NWI-11.

Introduction

Currently, the RIPE database supports email addresses encoded in the Latin-1 character set. However an email address can have an Internationalised Domain Name (IDN), with characters outside Latin-1 (i.e. Unicode). This causes interoperability problems as non-ASCII characters in an email address may not be accepted by a mail server, and only a small subset of Unicode characters can be encoded as Latin-1.

Solution Definition

In order to support Internationalised Domain Names (IDN) in an email address in the RIPE database, I propose to automatically encode email addresses in the Punycode format. Punycode (as defined in RFC 3492) is a way to encode strings containing Unicode characters, such as internationalised domain name (IDN) domains, into ASCII.

When updating the RIPE database, it is already possible to submit a Punycode encoded value (i.e. with ASCII encoding) for an email address value, but this change automates the conversion of any non-ASCII encoded email address to Punycode.

This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).

Automatic Punycode encoding will only be applied to the domain part of the email address. The local part of the address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.

When querying the RIPE database, any Punycode encoded email address is returned in Punycode (i.e it is not decoded).

I welcome feedback from the community on this proposal.

Regards
Ed Shryane
RIPE NCC


On 22 Jun 2020, at 22:49, ripedenis--- via db-wg <db-wg _at_ ripe _dot_ netdb-wg _at_ ripe _dot_ net>> wrote:

Colleagues

There has been some discussion recently and many times over the years about addressing this issue. The chairs believe there has been enough support shown to move forward with this. We would therefore like to present this as 'NWI-11 Internationalised Domain Names'. We propose a problem statement based on the text provided recently by Leo Vegoda, as shown below.

The RIPE NCC has a proposal for a solution to this problem using punycode. We would like to ask the RIPE NCC to present this proposal to the working group. If anyone has any other proposals for a solution, we welcome a discussion on this matter.

cheers
denis

co-chair DB-WG


Problem Statement

The RIPE NCC service region includes countries whose language is not written using Latin script. Many of the languages used in the RIPE NCC service region are written in Latin script but use diacritical marks that fall outside the US-ASCII character set. Internationalized Domain Names (IDNs) support the use of these scripts in DNS.

ICANN began delegating IDN Top-Level Domains as part of a test program in 2007 and the IETF updated the IDNA protocol in 2008 and as of mid 2020, there were over 160 IDN TLDs in the root zone.

The IETF published eight standards track RFCs on using IDNs in e-mail in 2012 and 2013. It is reasonable that organizations communicating with people whose preferred script is not Latin-based would want to use an IDN domain for e-mail as well as a web presence. It is also likely that the registry for an IDN TLD would want to use that TLD for its e-mail addresses.

RFC 3912 explicitly notes that the WHOIS protocol has not been internationalized while recognizing that some servers attempt to do so. RDAP has been deployed by the RIPE NCC and explicitly supports internationalization by UTF-8 encoding all queries and responses.

The RIPE community could decide to ignore EAI by trying to require organizations to deploy a secondary e-mail address for use in the RIPE Database. This would reduce the effectiveness of the RIPE Database as the secondary address is less likely to be monitored and used, and so be ineffective.



Benedikt Neuffer

2020-07-07 17:00:47 CET

Hi Ed,

On 07.07.20 15:20, Edward Shryane wrote:
> Hello Gert, Benedikt,
> 
>> On 7 Jul 2020, at 15:03, Gert Doering via db-wg <db-wg _at_ ripe _dot_ net> wrote:
>>
>> Hi,
>>
>> On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote:
>>> I don't get it. Does the RIPE DB prevent the usage of punycode?
>>>
>>> Can someone give me an example, where punycode doesn't work or why
>>> punycode isn't good enough?
>>
>> From what I understand, the intent is to convert incoming e-mail:
>> attributes in "non-punycode format" to punycode before storing in the DB.
>>
> 
> You are correct. 
> 
> From my Solution Definition:
> 
> "When updating the RIPE database, it is already possible to submit a Punycode encoded value (i.e. with ASCII encoding) for an email address value, but this change automates the conversion of any non-ASCII encoded email address to Punycode."
> 
> This automated conversion will allow any email address with an IDN (non-ASCII) domain name to be stored as Punycode.

ok, thanks for the details. Know I understand the intention. I think
that is the best thing one can do for now.

I am in for this change.

Regards,
Bene


Benedikt Neuffer

2020-07-07 17:03:01 CET

Hi Gert,

On 07.07.20 15:03, Gert Doering wrote:
> Hi,
> 
> On Tue, Jul 07, 2020 at 02:53:47PM +0200, Benedikt Neuffer via db-wg wrote:
>> I don't get it. Does the RIPE DB prevent the usage of punycode?
>>
>> Can someone give me an example, where punycode doesn't work or why
>> punycode isn't good enough?
> 
> From what I understand, the intent is to convert incoming e-mail:
> attributes in "non-punycode format" to punycode before storing in the DB.
> 
> I do not have a very strong opinion on this proposed implementation.
> 
> 
> In the long run, I think punycode is a horrible, horrible hack and must
> die in flames.  So if we can have a proper database with proper charset
> support, my surname would appreciate.
> 
> And yes, this will most likely involve UTF-8 internally and export filters
> (I do not want to see UTF-8, ever, if I can have ISO8859-15 instead - yeah,
> come, sue me)

I think at the moment it would be easier to update the clients to
convert punycode in whatever encoding you prefer.

Regards,
Benedikt


User Image

Gert Doering

2020-07-07 17:21:28 CET

Hi,

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

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Nick Hilliard

2020-07-07 23:53:40 CET

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


ripedenis@yahoo.co.uk

2020-07-08 03:03:47 CET

 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 <db-wg _at_ ripe _dot_ net> 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


  
User Image

Leo Vegoda

2020-07-08 04:00:35 CET

On Tue, Jul 7, 2020 at 6:05 PM ripedenis--- via db-wg <db-wg _at_ ripe _dot_ net> wrote:
>
> 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:

I think we need to consider the whole registry and not just the RIPE
Database. The creation of objects to describe organizations is still
relatively new. That information was placed in the RIPE Database, but
it could have been placed elsewhere, with an outward link from the
RIPE Database.

> -Should we allow all/some/none of the data content to be in non Latin characters?

Cynthia's message from earlier today [1] gives at least one case where
it would be useful to present names in a format that aids searching in
external data sources.

I support adding good support for internationalization in the RIPE
registry. I'd like it to be done in a way that minimizes the chance of
surprising organizations who miss a few announcements and find their
tools breaking because of character set issues.

Kind regards,

Leo Vegoda

[1] https://www.ripe.net/ripe/mail/archives/db-wg/2020-July/006567.html

User Image

Gert Doering

2020-07-08 08:03:45 CET

Hi,

On Tue, Jul 07, 2020 at 10:53:40PM +0100, Nick Hilliard wrote:
> 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?

That was my suggestion.  UTF8 internal, with an output filter to 
whatever charset the client can handle, possibly defaulting to ISO8859-1
on "whois" sessions.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

George Michaelson

2020-07-10 02:15:28 CET

>From outside your region, but since we run a "fork" of the RIPE DB
code, I would like to add some comments.

APNIC has seen clear demand from our community for multiple language
alternatives to be possible for at least these attributes:  contact
address (all parts), person names and org names.  It seems to make
sense to include remarks as well. This is a strong, continuing signal
of interest, concern from our region.

It’s not a case of having whois objects in “other languages”, but of
allowing multiple additional language versions of existing attributes
(allowing policy to still require latin script attributes). This is
analogous to RDAP where the data model has explicitly allowed us to
tag the objects/elements as having alternates.

The need comes from the fact that the primary language/script for
these things is the local language, not English. Making whois less
useful for communities in those countries/economies, and less likely
to be accurate. Having to coerce data into western/english script is
reducing the value proposition behind the service.

Raw UTF-8 would work better here. It would permit the model to be
extended naturally into multiple script models. I understand its
inherently more complex than uplift to punycode of the domain elements
in things, but the underlying problem in Whois and language goes
beyond the specific domain-name context.

I guess I am saying "I agree with Gert and I think my community wants this too"

-George

On Wed, Jul 8, 2020 at 4:04 PM Gert Doering via db-wg <db-wg _at_ ripe _dot_ net> wrote:
>
> Hi,
>
> On Tue, Jul 07, 2020 at 10:53:40PM +0100, Nick Hilliard wrote:
> > 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?
>
> That was my suggestion.  UTF8 internal, with an output filter to
> whatever charset the client can handle, possibly defaulting to ISO8859-1
> on "whois" sessions.
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Nick Hilliard

2020-07-13 16:41:35 CET

George Michaelson via db-wg wrote on 10/07/2020 01:15:
> Raw UTF-8 would work better here. It would permit the model to be
> extended naturally into multiple script models. I understand its
> inherently more complex than uplift to punycode of the domain elements
> in things, but the underlying problem in Whois and language goes
> beyond the specific domain-name context.
> 
> I guess I am saying "I agree with Gert and I think my community wants this too"

fundamentally yeah - it's a bit colonial to continue ignoring the 
reality that us-ascii is inappropriate for large chunks of the world.

Nick

ripedenis@yahoo.co.uk

2020-07-13 18:49:16 CET

 Hi Nick, George
"fundamentally yeah - it's a bit colonial to continue ignoring the reality that us-ascii is inappropriate for large chunks of the world."
I totally agree with the drive to disengage with the colonial past and move on in all areas of life. However, the RIR Databases reflect a public global registry of IP addresses, and in parts also serve as IRRs. If we are going to allow all character sets within these databases then we must answer a number of non technical questions, such as:-What is a global IP address registry?-What purpose does it/do they serve?-Who is it for?-Who needs to be able to read, understand, interpret, convert what parts of it?
Before we even ask those questions we need to consider who is going to answer these questions and on whose behalf? Is this going to be addressed separately by each RIR? Or is it better to consider a cross RIR Database/Registry solution?
This is why I believe we should go for a simple Punycode option now and then start to consider the bigger picture and finally address difficult questions that have been brushed under the carpet for many years.
cheersdenis
co-chair DB-WG

    On Monday, 13 July 2020, 16:42:01 CEST, Nick Hilliard via db-wg <db-wg _at_ ripe _dot_ net> wrote:  
 
 George Michaelson via db-wg wrote on 10/07/2020 01:15:
> Raw UTF-8 would work better here. It would permit the model to be
> extended naturally into multiple script models. I understand its
> inherently more complex than uplift to punycode of the domain elements
> in things, but the underlying problem in Whois and language goes
> beyond the specific domain-name context.
> 
> I guess I am saying "I agree with Gert and I think my community wants this too"

fundamentally yeah - it's a bit colonial to continue ignoring the 
reality that us-ascii is inappropriate for large chunks of the world.

Nick

  
User Image

Gert Doering

2020-07-13 20:54:08 CET

Hi,

On Mon, Jul 13, 2020 at 04:49:16PM +0000, ripedenis--- via db-wg wrote:
> This is why I believe we should go for a simple Punycode option now and then start to consider the bigger picture and finally address difficult questions that have been brushed under the carpet for many years.

I think nobody is disagreeing with you there - as long as we get going :-)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

George Michaelson

2020-07-14 04:30:53 CET

I would be broadly supportive of a cross-RIR database/registry
conversation. I think its long overdue.

It's not an easy conversation, but I think it's a necessary one.

it is also off-topic. So I won't say more, but having opened the door,
I strongly urge you to continue opening this door.

I believe the NRO would want us to explore this. From things said to
me at large, I am sure the community at large wants us to explore
this. They are very tired of information model and interface
divergences here.

-G

On Tue, Jul 14, 2020 at 4:54 AM Gert Doering <gert _at_ space _dot_ net> wrote:
>
> Hi,
>
> On Mon, Jul 13, 2020 at 04:49:16PM +0000, ripedenis--- via db-wg wrote:
> > This is why I believe we should go for a simple Punycode option now and then start to consider the bigger picture and finally address difficult questions that have been brushed under the carpet for many years.
>
> I think nobody is disagreeing with you there - as long as we get going :-)
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

ripedenis@yahoo.co.uk

2020-07-23 12:00:28 CET

Hi Ed
The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
cheersdenis
co-chair DB-WG
User Image

Ed Shryane

2020-07-29 17:02:11 CET

RIPE NCC staff member

Dear Colleagues,

Here is the impact analysis for the NWI-11 implementation.

The Database team plans to implement NWI-11 as per the Solution Definition:
https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html

(1) Impact to Whois Update

The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update. 

The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
	- ASCII encoded values will not be affected (as before).
	- Non-ASCII but latin-1 encoded values will be encoded as Punycode.
	- Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.

The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.

This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).

If an email address is converted to Punycode, a warning will be included in the update response.

Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.

(2) Impact to Whois Query

When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).

(3) Impact to Existing Data

We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.

(4) Impact to Whois Documentation

We will update the database documentation with details of this behaviour change.

(5) Release Timeline

We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.

As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.

Regards
Ed Shryane
RIPE NCC



> On 23 Jul 2020, at 12:00, ripedenis _at_ yahoo.co _dot_ uk wrote:
> 
> Hi Ed
> 
> The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
> 
> cheers
> denis
> 
> co-chair DB-WG

User Image

Leo Vegoda

2020-07-29 18:20:01 CET

Hi,

Thanks for providing the impact analysis for this initial change.

What should the process be for introducing greater support for
internationalization in the RIPE Database? George, Cynthia and others
have made good points about the need to improve internationalization
of more than just e-mail addresses. Is that support something that
should be handled through the process that follows the final report of
the Database TF or does it need to be addressed separately?

Thanks,

Leo

On Wed, Jul 29, 2020 at 8:03 AM Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:
>
> Dear Colleagues,
>
> Here is the impact analysis for the NWI-11 implementation.
>
> The Database team plans to implement NWI-11 as per the Solution Definition:
> https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html
>
> (1) Impact to Whois Update
>
> The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update.
>
> The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
> - ASCII encoded values will not be affected (as before).
> - Non-ASCII but latin-1 encoded values will be encoded as Punycode.
> - Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.
>
> The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
>
> This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).
>
> If an email address is converted to Punycode, a warning will be included in the update response.
>
> Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.
>
> (2) Impact to Whois Query
>
> When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).
>
> (3) Impact to Existing Data
>
> We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.
>
> (4) Impact to Whois Documentation
>
> We will update the database documentation with details of this behaviour change.
>
> (5) Release Timeline
>
> We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.
>
> As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.
>
> Regards
> Ed Shryane
> RIPE NCC
>
>
>
> On 23 Jul 2020, at 12:00, ripedenis _at_ yahoo.co _dot_ uk wrote:
>
> Hi Ed
>
> The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
>
> cheers
> denis
>
> co-chair DB-WG
>
>

ripedenis@yahoo.co.uk

2020-07-29 19:44:00 CET

 Hi Leo
As I have said many times, internationalising the RIPE Database is not a technical issue, it is a registry issue. I think it does need a separate process from the database requirements. Especially if we consider it as a cross registry issue.
Incidentally I did suggest on this mailing list several months ago that the requirements task force considers the issue of UTF-8. No one from the task force has yet replied to me on that or any other comment I have made about the requirements.
cheersdenis
co-chair DB-WG
    On Wednesday, 29 July 2020, 18:20:14 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:  
 
 Hi,

Thanks for providing the impact analysis for this initial change.

What should the process be for introducing greater support for
internationalization in the RIPE Database? George, Cynthia and others
have made good points about the need to improve internationalization
of more than just e-mail addresses. Is that support something that
should be handled through the process that follows the final report of
the Database TF or does it need to be addressed separately?

Thanks,

Leo

On Wed, Jul 29, 2020 at 8:03 AM Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:
>
> Dear Colleagues,
>
> Here is the impact analysis for the NWI-11 implementation.
>
> The Database team plans to implement NWI-11 as per the Solution Definition:
> https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html
>
> (1) Impact to Whois Update
>
> The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update.
>
> The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
> - ASCII encoded values will not be affected (as before).
> - Non-ASCII but latin-1 encoded values will be encoded as Punycode.
> - Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.
>
> The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
>
> This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).
>
> If an email address is converted to Punycode, a warning will be included in the update response.
>
> Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.
>
> (2) Impact to Whois Query
>
> When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).
>
> (3) Impact to Existing Data
>
> We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.
>
> (4) Impact to Whois Documentation
>
> We will update the database documentation with details of this behaviour change.
>
> (5) Release Timeline
>
> We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.
>
> As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.
>
> Regards
> Ed Shryane
> RIPE NCC
>
>
>
> On 23 Jul 2020, at 12:00, ripedenis _at_ yahoo.co _dot_ uk wrote:
>
> Hi Ed
>
> The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
>
> cheers
> denis
>
> co-chair DB-WG
>
>  
User Image

Leo Vegoda

2020-07-29 21:09:42 CET

Hi Denis,

I agree that this is a registry issue and not just a database issue,
which is why I sent the message I did on 8 July.

I'd like to understand how much of this work should be led by the RIPE
NCC versus the community. Also, because of the breadth of the issues,
should the discussion be here or on another list?

Kind regards,

Leo Vegoda

On Wed, Jul 29, 2020 at 10:45 AM ripedenis _at_ yahoo.co _dot_ uk
<ripedenis _at_ yahoo.co _dot_ uk> wrote:
>
> Hi Leo
>
> As I have said many times, internationalising the RIPE Database is not a technical issue, it is a registry issue. I think it does need a separate process from the database requirements. Especially if we consider it as a cross registry issue.
>
> Incidentally I did suggest on this mailing list several months ago that the requirements task force considers the issue of UTF-8. No one from the task force has yet replied to me on that or any other comment I have made about the requirements.
>
> cheers
> denis
>
> co-chair DB-WG
>
> On Wednesday, 29 July 2020, 18:20:14 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
>
>
> Hi,
>
> Thanks for providing the impact analysis for this initial change.
>
> What should the process be for introducing greater support for
> internationalization in the RIPE Database? George, Cynthia and others
> have made good points about the need to improve internationalization
> of more than just e-mail addresses. Is that support something that
> should be handled through the process that follows the final report of
> the Database TF or does it need to be addressed separately?
>
> Thanks,
>
> Leo
>
> On Wed, Jul 29, 2020 at 8:03 AM Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> >
> > Dear Colleagues,
> >
> > Here is the impact analysis for the NWI-11 implementation.
> >
> > The Database team plans to implement NWI-11 as per the Solution Definition:
> > https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html
> >
> > (1) Impact to Whois Update
> >
> > The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update.
> >
> > The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
> > - ASCII encoded values will not be affected (as before).
> > - Non-ASCII but latin-1 encoded values will be encoded as Punycode.
> > - Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.
> >
> > The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
> >
> > This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).
> >
> > If an email address is converted to Punycode, a warning will be included in the update response.
> >
> > Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.
> >
> > (2) Impact to Whois Query
> >
> > When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).
> >
> > (3) Impact to Existing Data
> >
> > We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.
> >
> > (4) Impact to Whois Documentation
> >
> > We will update the database documentation with details of this behaviour change.
> >
> > (5) Release Timeline
> >
> > We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.
> >
> > As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.
> >
> > Regards
> > Ed Shryane
> > RIPE NCC
> >
> >
> >
> > On 23 Jul 2020, at 12:00, ripedenis _at_ yahoo.co _dot_ uk wrote:
> >
> > Hi Ed
> >
> > The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
> >
> > cheers
> > denis
> >
> > co-chair DB-WG
> >
> >

ripedenis@yahoo.co.uk

2020-07-30 00:47:04 CET

 Hi Leo
Some of the questions that need to be answered include:
-who needs to be able to read/understand/interpret which parts of the data in the RIPE Database (maybe both the community and the NCC need input to answer this)?-is any of the data contained in the RIPE Database essential for the operation of the registry and not duplicated anywhere else (maybe the NCC and the NCC Services WG need input to answer this)?-is any of the data important to LEAs and governments, is that a consideration, do they have the resources to understand the data in any format (community and LEAs input needed for this one)?-One of the mission statements of the NRO is "Providing and promoting a coordinated Internet number registry system" so if we are going to internationalise the public face of the registry should it be coordinated(is that a community, RIR or NRO question)?
cheersdenis
co-chair DB-WG
    On Wednesday, 29 July 2020, 21:09:55 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:  
 
 Hi Denis,

I agree that this is a registry issue and not just a database issue,
which is why I sent the message I did on 8 July.

I'd like to understand how much of this work should be led by the RIPE
NCC versus the community. Also, because of the breadth of the issues,
should the discussion be here or on another list?

Kind regards,

Leo Vegoda

On Wed, Jul 29, 2020 at 10:45 AM ripedenis _at_ yahoo.co _dot_ uk
<ripedenis _at_ yahoo.co _dot_ uk> wrote:
>
> Hi Leo
>
> As I have said many times, internationalising the RIPE Database is not a technical issue, it is a registry issue. I think it does need a separate process from the database requirements. Especially if we consider it as a cross registry issue.
>
> Incidentally I did suggest on this mailing list several months ago that the requirements task force considers the issue of UTF-8. No one from the task force has yet replied to me on that or any other comment I have made about the requirements.
>
> cheers
> denis
>
> co-chair DB-WG
>
> On Wednesday, 29 July 2020, 18:20:14 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
>
>
> Hi,
>
> Thanks for providing the impact analysis for this initial change.
>
> What should the process be for introducing greater support for
> internationalization in the RIPE Database? George, Cynthia and others
> have made good points about the need to improve internationalization
> of more than just e-mail addresses. Is that support something that
> should be handled through the process that follows the final report of
> the Database TF or does it need to be addressed separately?
>
> Thanks,
>
> Leo
>
> On Wed, Jul 29, 2020 at 8:03 AM Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> >
> > Dear Colleagues,
> >
> > Here is the impact analysis for the NWI-11 implementation.
> >
> > The Database team plans to implement NWI-11 as per the Solution Definition:
> > https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html
> >
> > (1) Impact to Whois Update
> >
> > The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update.
> >
> > The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
> > - ASCII encoded values will not be affected (as before).
> > - Non-ASCII but latin-1 encoded values will be encoded as Punycode.
> > - Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.
> >
> > The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
> >
> > This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).
> >
> > If an email address is converted to Punycode, a warning will be included in the update response.
> >
> > Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.
> >
> > (2) Impact to Whois Query
> >
> > When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).
> >
> > (3) Impact to Existing Data
> >
> > We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.
> >
> > (4) Impact to Whois Documentation
> >
> > We will update the database documentation with details of this behaviour change.
> >
> > (5) Release Timeline
> >
> > We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.
> >
> > As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.
> >
> > Regards
> > Ed Shryane
> > RIPE NCC
> >
> >
> >
> > On 23 Jul 2020, at 12:00, ripedenis _at_ yahoo.co _dot_ uk wrote:
> >
> > Hi Ed
> >
> > The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
> >
> > cheers
> > denis
> >
> > co-chair DB-WG
> >
> >  
User Image

Leo Vegoda

2020-07-31 20:19:42 CET

Hi Denis,

These are good questions. As so many of the answers lie with the RIPE
NCC or the NRO, I suppose we need input from them to proceed further.

Kind regards,

Leo

On Wed, Jul 29, 2020 at 3:47 PM ripedenis _at_ yahoo.co _dot_ uk
<ripedenis _at_ yahoo.co _dot_ uk> wrote:
>
> Hi Leo
>
> Some of the questions that need to be answered include:
>
> -who needs to be able to read/understand/interpret which parts of the data in the RIPE Database (maybe both the community and the NCC need input to answer this)?
> -is any of the data contained in the RIPE Database essential for the operation of the registry and not duplicated anywhere else (maybe the NCC and the NCC Services WG need input to answer this)?
> -is any of the data important to LEAs and governments, is that a consideration, do they have the resources to understand the data in any format (community and LEAs input needed for this one)?
> -One of the mission statements of the NRO is "Providing and promoting a coordinated Internet number registry system" so if we are going to internationalise the public face of the registry should it be coordinated(is that a community, RIR or NRO question)?
>
> cheers
> denis
>
> co-chair DB-WG
>
> On Wednesday, 29 July 2020, 21:09:55 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
>
>
> Hi Denis,
>
> I agree that this is a registry issue and not just a database issue,
> which is why I sent the message I did on 8 July.
>
> I'd like to understand how much of this work should be led by the RIPE
> NCC versus the community. Also, because of the breadth of the issues,
> should the discussion be here or on another list?
>
> Kind regards,
>
> Leo Vegoda
>
> On Wed, Jul 29, 2020 at 10:45 AM ripedenis _at_ yahoo.co _dot_ uk
> <ripedenis _at_ yahoo.co _dot_ uk> wrote:
> >
> > Hi Leo
> >
> > As I have said many times, internationalising the RIPE Database is not a technical issue, it is a registry issue. I think it does need a separate process from the database requirements. Especially if we consider it as a cross registry issue.
> >
> > Incidentally I did suggest on this mailing list several months ago that the requirements task force considers the issue of UTF-8. No one from the task force has yet replied to me on that or any other comment I have made about the requirements.
> >
> > cheers
> > denis
> >
> > co-chair DB-WG
> >
> > On Wednesday, 29 July 2020, 18:20:14 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
> >
> >
> > Hi,
> >
> > Thanks for providing the impact analysis for this initial change.
> >
> > What should the process be for introducing greater support for
> > internationalization in the RIPE Database? George, Cynthia and others
> > have made good points about the need to improve internationalization
> > of more than just e-mail addresses. Is that support something that
> > should be handled through the process that follows the final report of
> > the Database TF or does it need to be addressed separately?
> >
> > Thanks,
> >
> > Leo
> >
> > On Wed, Jul 29, 2020 at 8:03 AM Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> > >
> > > Dear Colleagues,
> > >
> > > Here is the impact analysis for the NWI-11 implementation.
> > >
> > > The Database team plans to implement NWI-11 as per the Solution Definition:
> > > https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html
> > >
> > > (1) Impact to Whois Update
> > >
> > > The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update.
> > >
> > > The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
> > > - ASCII encoded values will not be affected (as before).
> > > - Non-ASCII but latin-1 encoded values will be encoded as Punycode.
> > > - Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.
> > >
> > > The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
> > >
> > > This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).
> > >
> > > If an email address is converted to Punycode, a warning will be included in the update response.
> > >
> > > Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.
> > >
> > > (2) Impact to Whois Query
> > >
> > > When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).
> > >
> > > (3) Impact to Existing Data
> > >
> > > We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.
> > >
> > > (4) Impact to Whois Documentation
> > >
> > > We will update the database documentation with details of this behaviour change.
> > >
> > > (5) Release Timeline
> > >
> > > We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.
> > >
> > > As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.
> > >
> > > Regards
> > > Ed Shryane
> > > RIPE NCC
> > >
> > >
> > >
> > > On 23 Jul 2020, at 12:00, ripedenis _at_ yahoo.co _dot_ uk wrote:
> > >
> > > Hi Ed
> > >
> > > The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
> > >
> > > cheers
> > > denis
> > >
> > > co-chair DB-WG
> > >
> > >

ripedenis@yahoo.co.uk

2020-08-05 14:46:09 CET

 Colleagues
We have a problem with UTF-8. Many people keep saying you want it, we should have it, lets do it...But every time we get to these difficult, non technical questions every one goes silent. This is why we have never implemented UTF-8 since it was first mentioned many years ago. No one in the community seems to know how to answer these questions.
So I have a suggestion. The RIPE NCC has the manpower with the expertise to investigate these issues. I propose we put a task on the RIPE NCC to do a thorough investigation of UTF-8 in the RIPE Database from all possible angles and report back to the community. This can be a starting point to a more meaningful discussion.
We need to know what impact having non Latin1 characters in different parts of the data set will have on the RIPE Registry, the RIPE NCC members, the different user groups of the RIPE Database and the social, legal and political impact of such a change. Which parts of the data set can/should/shouldn't be allowed to be in other character sets. Who really needs access to this data and what parts of it need to be understandable or interpreted. Which does bring into question the whole purpose of the RIPE Database and the data contained therein.
Thoughts???
cheersdenis
co-chair DB-WG


    On Friday, 31 July 2020, 20:20:10 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:  
 
 Hi Denis,

These are good questions. As so many of the answers lie with the RIPE
NCC or the NRO, I suppose we need input from them to proceed further.

Kind regards,

Leo

On Wed, Jul 29, 2020 at 3:47 PM ripedenis _at_ yahoo.co _dot_ uk
<ripedenis _at_ yahoo.co _dot_ uk> wrote:
>
> Hi Leo
>
> Some of the questions that need to be answered include:
>
> -who needs to be able to read/understand/interpret which parts of the data in the RIPE Database (maybe both the community and the NCC need input to answer this)?
> -is any of the data contained in the RIPE Database essential for the operation of the registry and not duplicated anywhere else (maybe the NCC and the NCC Services WG need input to answer this)?
> -is any of the data important to LEAs and governments, is that a consideration, do they have the resources to understand the data in any format (community and LEAs input needed for this one)?
> -One of the mission statements of the NRO is "Providing and promoting a coordinated Internet number registry system" so if we are going to internationalise the public face of the registry should it be coordinated(is that a community, RIR or NRO question)?
>
> cheers
> denis
>
> co-chair DB-WG
>
> On Wednesday, 29 July 2020, 21:09:55 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
>
>
> Hi Denis,
>
> I agree that this is a registry issue and not just a database issue,
> which is why I sent the message I did on 8 July.
>
> I'd like to understand how much of this work should be led by the RIPE
> NCC versus the community. Also, because of the breadth of the issues,
> should the discussion be here or on another list?
>
> Kind regards,
>
> Leo Vegoda
>
> On Wed, Jul 29, 2020 at 10:45 AM ripedenis _at_ yahoo.co _dot_ uk
> <ripedenis _at_ yahoo.co _dot_ uk> wrote:
> >
> > Hi Leo
> >
> > As I have said many times, internationalising the RIPE Database is not a technical issue, it is a registry issue. I think it does need a separate process from the database requirements. Especially if we consider it as a cross registry issue.
> >
> > Incidentally I did suggest on this mailing list several months ago that the requirements task force considers the issue of UTF-8. No one from the task force has yet replied to me on that or any other comment I have made about the requirements.
> >
> > cheers
> > denis
> >
> > co-chair DB-WG
> >
> > On Wednesday, 29 July 2020, 18:20:14 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
> >
> >
> > Hi,
> >
> > Thanks for providing the impact analysis for this initial change.
> >
> > What should the process be for introducing greater support for
> > internationalization in the RIPE Database? George, Cynthia and others
> > have made good points about the need to improve internationalization
> > of more than just e-mail addresses. Is that support something that
> > should be handled through the process that follows the final report of
> > the Database TF or does it need to be addressed separately?
> >
> > Thanks,
> >
> > Leo
> >
> > On Wed, Jul 29, 2020 at 8:03 AM Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> > >
> > > Dear Colleagues,
> > >
> > > Here is the impact analysis for the NWI-11 implementation.
> > >
> > > The Database team plans to implement NWI-11 as per the Solution Definition:
> > > https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html
> > >
> > > (1) Impact to Whois Update
> > >
> > > The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update.
> > >
> > > The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
> > > - ASCII encoded values will not be affected (as before).
> > > - Non-ASCII but latin-1 encoded values will be encoded as Punycode.
> > > - Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.
> > >
> > > The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
> > >
> > > This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).
> > >
> > > If an email address is converted to Punycode, a warning will be included in the update response.
> > >
> > > Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.
> > >
> > > (2) Impact to Whois Query
> > >
> > > When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).
> > >
> > > (3) Impact to Existing Data
> > >
> > > We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.
> > >
> > > (4) Impact to Whois Documentation
> > >
> > > We will update the database documentation with details of this behaviour change.
> > >
> > > (5) Release Timeline
> > >
> > > We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.
> > >
> > > As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.
> > >
> > > Regards
> > > Ed Shryane
> > > RIPE NCC
> > >
> > >
> > >
> > > On 23 Jul 2020, at 12:00, ripedenis _at_ yahoo.co _dot_ uk wrote:
> > >
> > > Hi Ed
> > >
> > > The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
> > >
> > > cheers
> > > denis
> > >
> > > co-chair DB-WG
> > >
> > >  
User Image

Chriztoffer Hansen

2020-08-05 15:29:26 CET

On Wed, 5 Aug 2020 at 14:46, ripedenis--- via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> We have a problem with UTF-8. Many people keep saying you want it, we should have it, let's do it...But every time we get to these difficult, non-technical questions every one goes silent. This is why we have never implemented UTF-8 since it was first mentioned many years ago. No one in the community seems to know how to answer these questions.
>
> So I have a suggestion. The RIPE NCC has the manpower with the expertise to investigate these issues. I propose we put a task on the RIPE NCC to do a thorough investigation of UTF-8 in the RIPE Database from all possible angles and report back to the community. This can be a starting point to a more meaningful discussion.
>
> We need to know what impact having non Latin1 characters in different parts of the data set will have on the RIPE Registry, the RIPE NCC members, the different user groups of the RIPE Database and the social, legal and political impact of such a change. Which parts of the data set can/should/shouldn't be allowed to be in other character sets. Who really needs access to this data and what parts of it need to be understandable or interpreted. Which does bring into question the whole purpose of the RIPE Database and the data contained therein.
>
> Thoughts???

+1 from me on this.

My primary reason for the +1 is being able to correctly spell the name
of $legal-entity (e.g. contact/representative person, company name).
Similar to how if you have your legal name changed. Your passport will
also need to be re-issued. I do not know how often this has been an
issue in the past. But I consider it high time to do something,
instead of, as you refer to denis, continue to "drag our feet". (the
world is larger than [0-9a-zA-Z]. The RIPE community does not walk "in
too-small shoes")

-- 
Best regards,
CHRIZTOFFER

User Image

Ed Shryane

2020-08-06 10:04:22 CET

RIPE NCC staff member

Hi Denis, Colleagues,

As you requested, the Database team will prepare a thorough investigation (impact analysis) of UTF-8 in the RIPE Database, as a starting point for further discussion.

Regards
Ed Shryane
RIPE NCC


> On 5 Aug 2020, at 14:46, ripedenis _at_ yahoo.co _dot_ uk wrote:
> 
> Colleagues
> 
> We have a problem with UTF-8. Many people keep saying you want it, we should have it, lets do it...But every time we get to these difficult, non technical questions every one goes silent. This is why we have never implemented UTF-8 since it was first mentioned many years ago. No one in the community seems to know how to answer these questions.
> 
> So I have a suggestion. The RIPE NCC has the manpower with the expertise to investigate these issues. I propose we put a task on the RIPE NCC to do a thorough investigation of UTF-8 in the RIPE Database from all possible angles and report back to the community. This can be a starting point to a more meaningful discussion.
> 
> We need to know what impact having non Latin1 characters in different parts of the data set will have on the RIPE Registry, the RIPE NCC members, the different user groups of the RIPE Database and the social, legal and political impact of such a change. Which parts of the data set can/should/shouldn't be allowed to be in other character sets. Who really needs access to this data and what parts of it need to be understandable or interpreted. Which does bring into question the whole purpose of the RIPE Database and the data contained therein.
> 
> Thoughts???
> 
> cheers
> denis
> 
> co-chair DB-WG
> 
> 
> 
> On Friday, 31 July 2020, 20:20:10 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org> wrote:
> 
> 
> Hi Denis,
> 
> These are good questions. As so many of the answers lie with the RIPE
> NCC or the NRO, I suppose we need input from them to proceed further.
> 
> Kind regards,
> 
> Leo
> 
> On Wed, Jul 29, 2020 at 3:47 PM ripedenis _at_ yahoo.co _dot_ uk ripedenis _at_ yahoo.co _dot_ uk>
> <ripedenis _at_ yahoo.co _dot_ uk ripedenis _at_ yahoo.co _dot_ uk>> wrote:
> >
> > Hi Leo
> >
> > Some of the questions that need to be answered include:
> >
> > -who needs to be able to read/understand/interpret which parts of the data in the RIPE Database (maybe both the community and the NCC need input to answer this)?
> > -is any of the data contained in the RIPE Database essential for the operation of the registry and not duplicated anywhere else (maybe the NCC and the NCC Services WG need input to answer this)?
> > -is any of the data important to LEAs and governments, is that a consideration, do they have the resources to understand the data in any format (community and LEAs input needed for this one)?
> > -One of the mission statements of the NRO is "Providing and promoting a coordinated Internet number registry system" so if we are going to internationalise the public face of the registry should it be coordinated(is that a community, RIR or NRO question)?
> >
> > cheers
> > denis
> >
> > co-chair DB-WG
> >
> > On Wednesday, 29 July 2020, 21:09:55 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org leo _at_ vegoda _dot_ org>> wrote:
> >
> >
> > Hi Denis,
> >
> > I agree that this is a registry issue and not just a database issue,
> > which is why I sent the message I did on 8 July.
> >
> > I'd like to understand how much of this work should be led by the RIPE
> > NCC versus the community. Also, because of the breadth of the issues,
> > should the discussion be here or on another list?
> >
> > Kind regards,
> >
> > Leo Vegoda
> >
> > On Wed, Jul 29, 2020 at 10:45 AM ripedenis _at_ yahoo.co _dot_ uk ripedenis _at_ yahoo.co _dot_ uk>
> > <ripedenis _at_ yahoo.co _dot_ uk ripedenis _at_ yahoo.co _dot_ uk>> wrote:
> > >
> > > Hi Leo
> > >
> > > As I have said many times, internationalising the RIPE Database is not a technical issue, it is a registry issue. I think it does need a separate process from the database requirements. Especially if we consider it as a cross registry issue.
> > >
> > > Incidentally I did suggest on this mailing list several months ago that the requirements task force considers the issue of UTF-8. No one from the task force has yet replied to me on that or any other comment I have made about the requirements.
> > >
> > > cheers
> > > denis
> > >
> > > co-chair DB-WG
> > >
> > > On Wednesday, 29 July 2020, 18:20:14 CEST, Leo Vegoda <leo _at_ vegoda _dot_ org leo _at_ vegoda _dot_ org>> wrote:
> > >
> > >
> > > Hi,
> > >
> > > Thanks for providing the impact analysis for this initial change.
> > >
> > > What should the process be for introducing greater support for
> > > internationalization in the RIPE Database? George, Cynthia and others
> > > have made good points about the need to improve internationalization
> > > of more than just e-mail addresses. Is that support something that
> > > should be handled through the process that follows the final report of
> > > the Database TF or does it need to be addressed separately?
> > >
> > > Thanks,
> > >
> > > Leo
> > >
> > > On Wed, Jul 29, 2020 at 8:03 AM Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net db-wg _at_ ripe _dot_ net>> wrote:
> > > >
> > > > Dear Colleagues,
> > > >
> > > > Here is the impact analysis for the NWI-11 implementation.
> > > >
> > > > The Database team plans to implement NWI-11 as per the Solution Definition:
> > > > https://www.ripe.net/ripe/mail/archives/db-wg/2020-June/006525.html 
> > > >
> > > > (1) Impact to Whois Update
> > > >
> > > > The implementation will automatically apply Punycode encoding (as per RFC 5891) to the domain part of an email address during Whois update.
> > > >
> > > > The encoding is only applied to an IDN domain name, and changes the current behaviour as follows:
> > > > - ASCII encoded values will not be affected (as before).
> > > > - Non-ASCII but latin-1 encoded values will be encoded as Punycode.
> > > > - Non-latin-1 encoded values (e.g. UTF-8) will also be encoded as Punycode. These values previously were transformed to latin-1, with a '?' substitution.
> > > >
> > > > The local part of an email address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid.
> > > >
> > > > This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to).
> > > >
> > > > If an email address is converted to Punycode, a warning will be included in the update response.
> > > >
> > > > Any Punycode conversion failure will result in the attribute value being rejected as invalid. A workaround in this case is to encode the value before submitting the update.
> > > >
> > > > (2) Impact to Whois Query
> > > >
> > > > When querying the RIPE database, any Punycode encoded email address is returned as-is (i.e it is not decoded).
> > > >
> > > > (3) Impact to Existing Data
> > > >
> > > > We will perform a cleanup to convert any existing non-ASCII (but latin-1 encoded) IDN domain names to Punycode in attributes with an email address syntax. This affects very few objects. The maintainer(s) will be notified by email beforehand.
> > > >
> > > > (4) Impact to Whois Documentation
> > > >
> > > > We will update the database documentation with details of this behaviour change.
> > > >
> > > > (5) Release Timeline
> > > >
> > > > We expect the NWI-11 implementation to take about 1 month (including code changes and testing), and will include the feature in the Whois 1.98 release.
> > > >
> > > > As usual, we will deploy the release to the Release Candidate environment for 2 weeks before production, to allow for testing.
> > > >
> > > > Regards
> > > > Ed Shryane
> > > > RIPE NCC
> > > >
> > > >
> > > >
> > > > On 23 Jul 2020, at 12:00, ripedenis _at_ yahoo.co _dot_ uk ripedenis _at_ yahoo.co _dot_ uk> wrote:
> > > >
> > > > Hi Ed
> > > >
> > > > The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database.
> > > >
> > > > cheers
> > > > denis
> > > >
> > > > co-chair DB-WG
> > > >
> > > >