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@yahoo.co.uk <ripedenis@yahoo.co.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@vegoda.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@ripe.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@yahoo.co.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